Messages in this thread |  | | | Date | Sun, 6 Dec 2009 16:39:30 -0500 | | From | tytso@mit ... | | Subject | Re: [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
|  |