On 9/11/06, Jonathan Pryor <[EMAIL PROTECTED]> wrote: > On Sun, 2006-09-10 at 21:07 -0700, Valient Gough wrote: > I think this is why they changed `struct fuse_operations' to deprecate > the getdir() method and replaced it with a readdir() method which > provides a `struct stat' to the filler function pointer. This change > requires FUSE 2.3, and setting the FUSE_USE_VERSION macro in order to > use it. I see that neither Sulf nor fusewrapper set this macro.
The getdir() / readdir() changes don't affect my wrappers - those are for the path based API. > >From what I can gather from email archives, they added the readdir() > replacement precisely because of apps like Mutt, so that the filesystem > programs could provide an inode for stability tracking purposes. Yes, but this is only vaguely related. You might have noticed that I reported that problem, and I think even provided some of the changes to help with this case. One of the tricks Mutt does is create hard links and then check that the inode numbers were identical as a race-condition check. That solves one particular problem with Mutt running under a virtual FS. That's the interesting thing with running random programs under a filesystem - you find out that behavior which programs expect isn't necessarily guaranteed by the filesystem documentation. > The current Mono.Fuse.FileSystem.OnReadDirectory() method now allows > providing this `struct stat' information, so hopefully things should > work sanely (though I have yet to actually test it, and coming up with > an a good test case which exercises reading, writing, and renaming > concurrently is difficult). There is a program "fsx-linux" which you might find useful. I've found bugs in FUSE itself with this program in the past while trying to debug my own filesystems. > Also, a file can't be deleted while it's still open if the *Handle > methods use file descriptors, as even after OnRemoveFile() is called the > file handle would still be valid, and won't be invalided until > OnReleaseHandle() is called. The same should be true for directories, > if a directory handle is used (again, see > example/RedirectFS/RedirectFS-FH.cs). I wrote a fair amount of the rename and delete handling code in libfuse, which has been there since version 1.9, so I feel confident in describing how it works. You're right that a file handle will still be valid, but the path name will have changed. The NFS trick is used for the path-based API (unnecessary with the inode api) - a delete is turned into a synchronized rename with the final delete postponed until files are closed. Did you try rsync and Evolution? They really do create lots of rename-while-open events that are useful for testing assumptions related to the primary key (path in your case). Now consider edge cases related to this NFS trick. Consider that you have an open file and the file is removed. Now the directory is supposed to be empty (although because of the NFS trick it isn't) and the directory is removed. Does it succeed, or does it fail, and does it match what a program might expect from a 'normal' filesystem? No point arguing about what we expect to happen - rsync can cause such a condition, or it could be constructed by hand, so it is easy to test. Sounds like minor issues, and they are mostly. Only a few programs will probably be affected, and most of them in a way that doesn't cause an serious problem (meaning data loss). If the broken programs are used by few people, it may takes years to hear about it. But if it causes Evolution to corrupt its db files, the feedback may not be so friendly. regards, Valient PS. You know about the language wrapper FUSE wiki page? (http://fuse.sourceforge.net/wiki/index.php/LanguageBindings). Might want to list your wrapper so that people outside mono-devel can find it. _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list