lkml.org 
[lkml]   [2009]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 0/5] pathconf(3) with _PC_LINK_MAX
On Sun, Dec 06, 2009 at 08:39:58AM +0000, Al Viro wrote:
>
> Um... Why do we need that, again? Note that there is no way whatsoever
> for predicting whether link(2) will fail due to having too many existing
> links before you attempt the call - links can be created or removed between
> stat(2) and link(2). So any uses of that value are heuristical.
>
> Can you actually show any use cases of that thing? Preferably - in existing
> code, but even a theoretical one would be interesting.

I think it's mainly a "if we're going to implement a POSIX interface,
it would be nice if it returned something based on reality instead of
a wild-assed guess". :-)

The "real life" use case I could think of is that backup programs that
use hard links everywhere would be able to determine ahead of time in
advance when it might need to create a new file instead of using a
hard link, without needing to do the link and getting the EMLINK
error. I agree that the only way you can know for sure is by actually
trying the link, so it's a pretty feeble use case.

I will note that without a functional, ext3 and ext4 (or ext3
filesystem with dir_nlink file system feature mounted with ext4) file
systems would be indistinguishable.

- Ted


\
 
 \ /
  Last update: 2009-12-06 22:43    [W:0.045 / U:11.820 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site