So a value of 0 would have the same effect.
(0 - 2 == -2 vs 1 - 2 == -1) Yes?
>
>
> I'm not sure exactly what nlink is used for in userspace for regular
> files, so I don't know what value should be used when the real number
> doesn't fit in the interface.
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".
> (Of course new directories/hardlinks shouldn't be created at all once
> the limit is exceeded, the above is only a workaround for people that
> need it anyway :) )
It should not fail just because the type specified for
st_nlink has overflowed. It should fail only if the FS or
kernel internals overflow. Internally the kernel is moving
to an unsigned int. I looked it up a recently and each
filesystem has it's own idea of a maximum number of links
and most of them are not just arbitrary but even strange
such as 32000 or 0x7FFF - 1000.
The stat structure has already been left behind on this.
Eventually (3.0?) it should be updated to reflect the
changed internals. This update has to be delayed because it
will break binary compatability of oodles of code. I, at
least, don't think this is worth creating yet another
version of stat(2).
-- ________________________________________________________________ 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/