heading sizes

[Imported from Trac: page SftpFrontend, version 44]

SftpFrontend.md

@@ -3,7 +3,7 @@ The SFTP frontend is a server that optionally runs as part of a gateway node, an
 See source:docs/frontends/FTP-and-SFTP.txt for how to enable and set up the SFTP frontend on a gateway. This page is for compatibility issues with particular SFTP clients, and assumes that you are using Tahoe-LAFS v1.7.0β or later. Please add any more issues that you discover.
 
 
-### Security
+# Security
 
 The security of the connection between the SFTP client and gateway is dependent on the PyCrypto library, which has not been reviewed to the same extent as the pycryptopp library that we use elsewhere in Tahoe-LAFS. In particular, the AES implementation in PyCrypto is known to be vulnerable to timing attacks which could potentially, depending on the situation, allow a remote attacker to break the encryption protecting the SFTP connection between your SFTP client and the Tahoe-LAFS gateway process that is acting as SFTP server. Therefore we do not recommend that you rely on the confidentiality or authentication provided by this SSH connection in the current release.
 
@@ -12,7 +12,7 @@ In practice, that means you can run the Tahoe-LAFS gateway locally on the same m
 Server keys with passphrases are not supported (#1039).
 
 
-### General compatibility issues
+# General compatibility issues
 
 Before uploading a file to a Tahoe filesystem, the whole file has to be available. This means that the upload can only start when the file has been closed in the SFTP session. Particularly when writing large files, the client may time out between sending the close request and receiving the response (ticket #1041). This is known to be a problem for at least the WinSCP client, which has a default close timeout of 15 seconds. In the case of WinSCP this can be worked around by setting WinSCP -> Connection -> Timeouts to 6000 seconds (the maximum allowed); other clients with this problem may have similar settings.
 
@@ -25,7 +25,7 @@ See the last section of [FTP-and-SFTP.txt]source:docs/frontends/FTP-and-SFTP.txt
 The '`ctime`' and '`mtime`' attributes will always be the same, and are set from the Tahoe `linkmotime` timestamp, which is changed only when the link from the parent directory is modified (see the 'About the metadata' section of [webapi.txt]source:doc/frontends/webapi.txt). These fields are not updated when the contents of a mutable file are changed. The SFTP protocol and the server are able to represent dates up to the year 2106, but some clients may print dates incorrectly after 2037.
 
 
-### Unicode filenames
+# Unicode filenames
 
 The SFTP frontend encodes all filenames as UTF-8 when communicating with the client. Support for displaying and copying non-ASCII filenames is likely to vary between clients. If you are using a filesystem that represents names as UTF-8 (including via sshfs), then it should just work, but please report your experience with this.
 
@@ -34,12 +34,12 @@ Some clients fail to convert filenames to UTF-8, or require a configuration opti
 As of Tahoe v1.7.0 final, filenames are normalized to NFC, which means that it is not possible to have two files/subdirectories with [canonically equivalent](http://en.wikipedia.org/wiki/Unicode_equivalence) names in the same directory. (This does not cause any incompatibility with filesystems that use a different normalization, such as NFD in Mac OS X.)
 
 
-### Performance
+# Performance
 
 The SFTP frontend currently performs no caching (sshfs does cache, but only for 20 seconds with the default settings). Some applications assume that file operations have relatively low latency, and may have very poor performance when working directly with a Tahoe filesystem. In this case it may be better to copy files to a local filesystem and work on them there, then copy back any changes. Note that just browsing a directory may cause some apps to perform many unnecessary reads or attribute checks of files in that directory.
 
 
-### Specific clients
+# Specific clients
 
 ## sshfs