Quick Summary No file locking. No Unix special files such as pipes, devices or symbolic links (although there is a workaround for symbolic links). No real file ownership.

3. Limitations

3.1 Qualitative Limits

• Sharity can't do file locking. If you have applications which rely on file locking, you currently can't use Sharity. Fortunately, file-locking is rarely used on Unix.
• No printer sharing. Sharity was developed as a filesystem tool and nothing else. There are other tools available to share printers, see the Samba documentation for details.
• No File ownership and Access Control Lists (ACLs). Sharity uses plain DOS file attributes. Although it can't display or modify ownership and ACL data, it is bound to the permissions granted by the server based on these attributes. We hope to implement some kind of access to ownership and ACLs in the next major release.
• No symbolic and hard links. Windows and thus CIFS does not have the concept of links. Sharity therefore can't implement them directly. It does, however, implement a method to fake symbolic links with ordinary files on the server. These faked symbolic links are only understood by other Sharity clients (and by CygWin32 on Windows, which is part of the GNUPro Toolkit).
• No device-files and named pipes. These are Unix features which have no equivalent in CIFS.
• Concurrent access to a file may not return up-to-date data. Sharity does some data caching in order to improve data throughput. CIFS defines exactly when and how this caching may be done. However, many servers don't support the functionality which controls caching. Sharity therefore caches files for a second longer than the server permits. This may cause inconsistencies if a file is written on the server and simultaneously read from a Sharity client. You can fix these problems by tweaking parameters with a negative impact on performance. Furthermore, there seem to be bugs in NT's implementation of the cache control. It sometimes (although only in rare cases) "forgets" to tell Sharity that it should invalidate its cache.

3.2 Resource Limits

Maximum file size:

Sharity currently connects to the kernel through the NFS2 protocol. This protocol is conceptually limited to 4 GB of maximum file size because file offsets and sizes are communicated in 32 bit entities. However, most operating systems use one of the 32 bits for the sign, effectively limiting Sharity to 2 GB of maximum file size.

Maximum share name length:

The CIFS browsing specification limits share names to at most 14 characters. If you want to browse shares in the /CIFS directory, you should adhere to that limit. If you mount a share directly with cifsmount from the commandline or with the GUI, the limit for computer names and shares is 254 characters. Note: Windows NT can browse shares with more than 14 characters since it uses a protocol not officially published by Microsoft.

Maximum number of files per share:

The absolute maximum number of files in a share is 16 millons. However, it's likely that you hit an other limit before you reach this one. The file lookup mechanism used by default needs roughly 20 bytes plus the size of the file name for every file accessed. This means that on an average share with 50,000 files with an average name length of 8 characters, Sharity may need up to 50,000 * 28 = 1.4MB of virtual memory for the file table, if you access all files.

Maximum file name length:

Sharity does not allow file names longer than 255 characters. Please note that NFS (Sharity is based on NFS internally) may impose a tighter limit: The maximum file name length of NFS is 255 bytes, which may be less than 255 characters if Unicode characters must be represented as multi-byte entities.

Maximum number of browsable entities:

The CIFS browsing protocol is limited by the server's buffer size for browse lists. These browse lists contain the names of the hosts in a workgroup or the shares exported by a host. The buffer size depends on the server software. If the limit is reached, Sharity logs an error to the system log. This usually happens at more than 1000 entries. Please note that "invisible" administrative shares count, too.

3.3 Browse Server Incompatibilities

• Samba
• Windows NT
• Windows 95
• Windows 98
• Windows ME
• Windows 2000

[global]
        local master = yes
        preferred master = yes
        os level = 65

        domain master = yes

3.4 rm -r Incompatibilities