Sharity 2 Manual: Limitations

3. Limitations

Sharity does not solve all problems on earth, of course. Although it has many advantages over others, Sharity is not always the best solution under all circumstances. Here's a list of things Sharity can't do, at least in the current version:

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.
  • No File ownership and Access Control Lists (ACLs). Sharity uses the 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. CIFS does not have the concept of links. Sharity therefore can't implement them. 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, which is part of the GNUPro Toolkit).
  • No device-files and named pipes. These are Unix features which have no equivalent in CIFS.

3.2 Resource Limits

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 or from the GUI, the limit for computer name and share 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.
Maximum file name length:
Sharity does not allow file names longer than 255 characters. Please note that NFS (Sharity is based on NFS) may impose a tighter limit: the maximum file name length of NFS is 255 bytes, which may be less 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. If the limit is reached, Sharity logs an error to the syslog. This usually happens at more than 1000 entries. Please note that "invisible" administrative shares count, too.

3.3 Browse Server Incompatibilities

For a list of compatible servers and clients, please see appendix Supported Platforms and Servers. However, not all CIFS servers mentioned in this appendix are compatible as browse servers. Since browse servers are negotiated automatically, an incompatible CIFS server might become the browse server in a heterogenous network. Sharity is known to work with the following CIFS servers as browse servers:
  • Samba
  • Windows NT
  • Windows 95
  • Windows 98
If you have problems with the browse server, we recommend that you install Samba on a Unix machine and configure it to become a preferred Local Master Browser. The following line of sama configuration do the trick:
[global]
        local master = yes
        preferred master = yes
        os level = 65
If you don't have a domain controller in your network, also add
        domain master = yes

3.4 rm -r Incompatibilities

Recursively deleting a large directory may fail on certain combinations of kernel and rm implementation. See the end of chapter Troubleshooting for details.


Sharity Manual for version 2.3 | Copyright (C) 1999 by Christian Starkjohann | http://www.obdev.at/