Re: st_size of a symlink

[Al Viro]

On Mon, Jul 23, 2012 at 08:09:14PM +0200, Jesper Juhl wrote:
> 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_?  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.

The fact is, st_size is just a useful hint for symlink target length.
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.
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.  By retrying readlink() with bigger buffer.
With procfs there's just a few more ways the readlink() output can
change, that's all.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/