Big archive storages may be overloaded by 'access time' attribute setting that CBFS driver generates by itself even on file read. This happen without outer file system request. Archiving of such events takes a lot of time in tape archives. Its not possible to separate events generated by driver and user' program. Would be good to have CBFS driver option 'no atime on close'.
Add "CbFsFileInfo.RenameOrMoveFile" flag similar to "CbFsFileInfo.DeleteFile"
CbFsFileInfo.DeleteFile is very useful information: DeleteFile=true in OnCloseFile says that OnDeleteFile will be invoked after OnCloseFile, so we can save some specific context information allocated in CbFsFileInfo.UserContext and free it in OnDeleteFile. OnRenameOrMoveFile callback comes without similar information, but specific context information is still required. We must keep this information allocated separately, manage it asynchronously some time a free it after timeout (little complicated thing, because this information contains session/user specific informations for network redirectors etc., we must correctly handle user-logout and other potentially collision situations). So adding CbFsFileInfo.RenameOrMoveFile would be nice. Sorry for my English. :)
CbFsEnumerateDirectory does 2 things and it would be nice to separate those 2.
When implementing the CBFS callbacks/events, I kind of struggled with the CbFsEnumerateDirectory event. After a while I realized that this event does actually 2 things. It scans through the directory, using a mask like '*', and it searches for a specific file using any other mask. Within my own code I was even able to completely separate those functions by switching on the mask. Having 2 meanings violates the single responsibility principle. It would be nice to have 2 events instead. One that only scans the directory, and one that searches for a specific file or folder. This would reduce a lot of plumbing and fiddling around with the EnumerationInfo.UserContext, and these events would be much easier to understand when you use this product for the first time.
Having to throw an exception for "GetFileSecurity" in .Net is messy
The first request to "GetFileSecurity" is normally to ascertain the size of the structure to be created. Having to throw a CBFSWinError Exception of "The data area passed to a system call is too small" is rather a messy way to just return that state and is very slow, i.e. the internal .Net code has to generate a call stack etc. which ultimately is thrown away.
Can the API through .Net have return Win32 error codes rather than exceptions ?> Still keep the exception handling, but if a call can be translated to a normal Win32 error code, then use that.
If this is the same in the Cpp (And other libraries) then use in there as well. This will give a significant speed improvement for _all_ of your customers.
If a worker doesn't receive a request within 60 seconds (possibly a user specified interval), that worker should trigger a OnRequestTimeout callback. This way, system resources can be re-used, removing the need to create even more threads. This callback could be used to trigger a keep-alive or perform program cache cleanup, possibly even reducing the number of worker threads.
Some sort of testsuite for the implemented filesystem. perhaps supporting nunit, mbunit or ncover. Since every filesystem using cbfs must have a common behavior it would be nice to have an easy way of checking the basic stuff.
Presently Delphi does not include support for 64 bit windows versions. It would be helpful if there was a FreePascal interface and example so that Delphi developers could support 64bit windows versions.
In case a local share is used as mirror path in applications like the CbFs Mapper Sample and the CbFs is accessed by a CIFS share sometimes a deadlock happen. It would be nice to enable this option for a easy usage of CbFs in a Windows Cluster.