Messages in this thread | | | Date | Fri, 6 Sep 2002 02:01:38 +0200 | From | Ragnar Kjørstad <> | Subject | Re: [reiserfs-dev] Re: [PATCH] sparc32: wrong type of nlink_t |
| |
On Thu, Sep 05, 2002 at 03:57:06PM -0700, jw schultz wrote: > > Now, I've just checked the source of GNU find (v4.1.7) and it does _not_ > > recognize nlink=1 as a special value. (It works as long as there are > > less than 2^32 subdirectories though, because it is looking for -1 > > subdirectories and it wraps) > > So a value of 0 would have the same effect. > (0 - 2 == -2 vs 1 - 2 == -1) Yes?
Yes, it will. For GNU find.
But the reasoning for using nlink==1 is that that's how "all non-unix filesystems" behaved, so applications out there could potentially check for it.
> I know it is used for reporting purposes such as ls -l. It > would also used by archiving tools like cpio, tar and rsync > to identify files that may be linked so that not every file > must be checked against every previous file. A smart > archiving tool would track the link count and remove entries > that have all links found so any value that isn't recognized > as an overflow indicator would tend to break things. I see > the value of 0 as indicating "link count unsupported".
Hmm, yes. Values of 1 or NLINK_MAX would definitively confuse such applications. But then again, so would a value of 0 unless they know it's meaning.
-- Ragnar Kjørstad - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |