Nice discussion. Even though I remember not being able to remove because of a bash waiting there, but probably was a zfs destroy.......and IMHO this is a more logic approach
I'll read the RFCs :) Thanx! Inviato da iPad Il giorno 05/giu/2012, alle ore 22:06, James Carlson <[email protected]> ha scritto: > Gabriele Bulfon wrote: >> I understand your point. >> But, my question is...shouldn't a network filesystem try to completely >> emulate a local file system, >> trying to hide as much as possible the fact of being a network share? > > Sure, although "try" is certainly the operative word here. > >> In this case, how does a local filesystem like ZFS or UFS manage these >> situations? > > A local file system doesn't have this problem, because the directory > entry is distinct from the "handle" that the program has on an open > file. An open local file essentially references the inode for that > file. If the directory entry (which points to the inode) is removed, > the program can keep on using the now-nameless inode without trouble. > When all references to the inode are dropped, the space is returned to > the free pool. > > (Depending on the OS, you may even be able to use link(2) to reattach an > unlinked but still open file by using the procfs nodes.) > > With NFS, the server doesn't know whether files are open or closed. If > the client actually removed the file, that would immediately invalidate > any other client handles, and break the applications still using the > now-unreferenced file. > > In short, this is just how NFS works. > >> Local file systems do not create .xxx files, and they never show up even in >> the situations you describe. > > True. Local file systems aren't remote. :-/ > >> So, why NFS should be different? I believe that the NFS server may hold this >> files for himself and >> the processes that already have opened sessions on them, not showing them in >> folder listings >> (as zfs can do with its .zfs folder). > > I suppose that NFS clients could be designed to hide these files from > the user optionally. It may well make some operations a little (or > perhaps a lot) strange, but I think it could be made to work. It's just > not how it's done today. > >> Also, is it correct by the file system to allow deletion of a file opened by >> someone else? > > Sure; standard UNIX/POSIX semantics apply. > >> For example, an "rm -r folder" will fail in case I have a bash inside it's >> tree. > > That's not true. In one window: > > % bash > carlsonj@carlson:/build/carlsonj$ mkdir foo > carlsonj@carlson:/build/carlsonj$ cd foo > carlsonj@carlson:/build/carlsonj/foo$ > > Now, in another window: > > carlsonj@carlson:/build/carlsonj$ rm -r foo > carlsonj@carlson:/build/carlsonj$ > > Now back in the first window: > > carlsonj@carlson:/build/carlsonj/foo$ /bin/pwd > pwd: cannot determine current directory! > carlsonj@carlson:/build/carlsonj/foo$ > > You can always remove anything you want to remove, assuming you have the > right permissions. Directory entries are just that -- directory > entries. They have the name of the object and a pointer to where the > object resides. They're not the object itself. > >> I believe an option to hide them would do no harm. > > Fortunately, it's an open process. Read RFCs 1813 and 3010 to start, > and propose your own design. > > -- > James Carlson 42.703N 71.076W <[email protected]> > > _______________________________________________ > OpenIndiana-discuss mailing list > [email protected] > http://openindiana.org/mailman/listinfo/openindiana-discuss _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
