On Mon, 23 Jul 2012, Al Viro wrote:

On Mon, Jul 23, 2012 at 08:09:14PM +0200, Jesper Juhl wrote:

quoted

So, from my point of view it looks like procfs is the one who has got it 
wrong.
We should probably fix that (IMVHO).

Fix it _how_?  

By returning the size as the number of bytes in the name the link is 
currently pointing at.

Try to rename a binary you have running in a process.
Or rename its cwd.  Or rename an opened file.  Watch the corresponding
procfs symlink (still pointing to the swame object) change.  With
no way to tell that some sucker had looked at st_size some time ago
and might get surprised by the change.

Sure, length's may change and an app needs to be prepared for that, but 
that's no reason to always return 0 (zero) for length for links in procfs.
We can do better and return the actual length of whatever the link is 
pointing to currently - just like other filesystems do.

The fact is, st_size is just a useful hint for symlink target length.

Sure.

It tells you the likely sufficient size of buffer.  There's a reason
why readlink(2) returns what it returns; you *can't* rely on the
earlier lstat() results or, for that matter, any prior information.

I know that. That's not the issue. The issue is that procfs *could* return 
more useful info than it does currently.

If nothing else, I could rm that symlink and create a new one in
the meanwhile.  You need to check what it had returned and deal with
insufficient buffer size.

Of course.

 By retrying readlink() with bigger buffer.
With procfs there's just a few more ways the readlink() output can
change, that's all.

Still not a good reason to just return 0 IMHO.


-- 
Jesper Juhl [off-list ref]       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html