[OpenIndiana-discuss] NFS hidden files

[James Carlson]

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>