Chris Wedgwood wrote:
As Ted said, not all fiel systems follow this. This means that such
applications cannot e.g., remove a directory (rm -r) from such a FS?
i don't know about rm, but some versions of find need -noleaf (see the
man page for details)
I am asking because we have an issue that an older version of mc
cannot remove directory recursively, however we have not observed
this on any new system. Might the nlink count be the problem?
i'm not seen the nlink problem occur because pretty much all
filesystems have nlink set correctly *or* they set it to one like
autofs does which happens to work because 1-2-n underflows (there are
also those who claim that nlink==1 implies you don't know how many
links there are)
Right. On most applications, it "just works" because of underflow (if
you treat nlink as unsigned and subtract 2, then you get UINT_MAX which
is functionally infinity.) This is a good reason for this particular
retcon.
The established practice is to set nlink to 1 if either you don't know
how many links there are or there are too many to fit in the nlink field.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
