Re: st_nlink of directory nodes in shadowfs

[Roland McGrath]

I think the principle of least astonishment dictates that the default
behavior of existing tools match what they do on existing systems.
That is, S_ISDIR should be the usual test applied by find and the
like.  I for one will be annoyed if I do "find . -name \*.o -print |
xargs rm" and it goes into my translator-provided tar-file directories
and removes the backup copies of my .o files.  

(I am not going to delve into the standards today, but I can imagine
it being the case that a careful reading of 1003.1+1003.2 mandates
that find's decision to descend must match S_ISDIR.  Of course that
might be deemed irrelevant on any system where you've done a
nonstandard thing like setting a tar-file translator.)

GNU find certainly ought to have switches to make possible all the
permutations of what you might really want to do given the Hurd
filesystem semantics.  That includes a switch to descend non-S_IFDIR
directories, akin to `-follow' for descending symlinks to directories,
as well as a switch to use O_NOTRANS, etc.

I think it is a reasonable convention that a translator use the S_IFMT
bits to indicate how it wants to be treated by normal POSIXish tools.
That seems like a sane convention for the Hurd in the abstract, and it
conveniently matches the de facto convention of all existing
filesystem-using tools and presumption of users familiar with other
POSIX systems.  For tar-file directories and other such cases, it
should be a command-line option to the translator so you can have it
either way depending on what you want for a particular case.

> Roland McGrath <roland@gnu.org> writes:
> 
> > Note, however, that this optimization in find will quite totally break the
> > filesystem semantics presented by translators set on regular files.  That
> > is, a translator set on a regular file may well report S_IFDIR and so a
> > find ought to treat it as a directory.  But the underlying node isn't a
> > directory and so doesn't have a .. node contributing to the containing
> > directory's link count.
> 
> This is a realy problem with find, and we should report it.
> (Actually, we should try and provide a patch.)
> 
> It opens a question: do we want the decision to hinge on whether
> S_IFDIR is returned?  The other thing is to test on whether it really
> is a subdir.  (Note that my earlier note about st_nlink is about
> subdirs, S_IFDIR.)
> 
> A real subdir, of course, is one that supports directory operations.  
> 
> Perhaps find should support both versions, and should have a user
> option to say which.  (That is, it being find, it should have
> predicates to detect which, and then a sane default.)  It begs the
> question of "what is the default", but whatever it is, it should be
> the same as is used by things like chmod -R and so forth.
> 
> I'm inclined to say the default should be to work on all real subdirs,
> whether they label themselves with S_IFDIR or not.
> 
> Thomas