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-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
