[OpenIndiana-discuss] NFS hidden files

[Gabriele Bulfon]

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 <carlsonj at workingcode.com> 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 at carlson:/build/carlsonj$ mkdir foo
> carlsonj at carlson:/build/carlsonj$ cd foo
> carlsonj at carlson:/build/carlsonj/foo$
> 
> Now, in another window:
> 
> carlsonj at carlson:/build/carlsonj$ rm -r foo
> carlsonj at carlson:/build/carlsonj$
> 
> Now back in the first window:
> 
> carlsonj at carlson:/build/carlsonj/foo$ /bin/pwd
> pwd: cannot determine current directory!
> carlsonj at 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         <carlsonj at workingcode.com>
> 
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss