On Fri, Sep 06, 2002 at 02:01:38AM +0200, Ragnar Kjørstad wrote:
> 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.
But we aren't talking about filesystems with different ideas
about directory linking. We are talking about directories
with an overflowed link-count.
> > 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.
The value of 1 can't be used for regular files because it
would mean the file doesn't need checking for other links.
Coding for NLINK_MAX would mean the apps would have to
adjust every time NLINK_MAX changed. Yes, it could be done
through #define in stat.h. It is a corner case right now
but these apps could know that
1 == no other links
>1 == known number of other links
0 == unknown number of other links
And the code would work on other systems with different or
no overflow/limit. So far as i know Linux is the only OS
that is allowing the creation of more links than 32767.
These apps are going to need to cope with this sooner or
later. Allowing nlinks to overflow st_nlink is going to
break them. Using 0 would mean that the application code to
handle this corner case would simply never get invoked on
other platforms without requiring build options. Sure 1 is
a red flag for directories (if you can spot it) but any
value greater than 0 is potentially valid for files.
That is why i lean toward 0. It is a clear indication that
the value is meaningless. It also sticks out like a sore
thumb. If i do an ls -l and see 0 i will know i've got a
reporting overflow without having to remember what the exact
limit is. This way i can do a 'find -links 0' and spot
directories and files with more links than fit etc. The
application code to cope with it won't break or require
special handling on other platforms.
So you see why i dislike NLINK_MAX and it just makes sens to me
to use the same for files and directories. Filesystems that
don't support hardlinks have been stuffing 1 into st_nlink
for both file and directories (treating them identically).
I am essentially saying we should treat files and directories
the same on overflow. We just shouldn't use some value that
in future could represent reality. Hence 0. So far i
haven't heard any reason why not.
NOTE:
Allowing the creation of links that exceed the capacity of
stat(2) to report will break utilities. There should be a
system wide tunable that allows restricting link creation to
a maximum number until the tools catch up. This tunable
would only affect link creation causing link(2) to set errno
to EMLINK. A mount option might be OK too.
This limit should not affect pseudo filesystems like
proc or driverfs.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - 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/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:28 EST