lkml.org 
[lkml]   [2012]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: st_size of a symlink
    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.


    \
     
     \ /
      Last update: 2012-07-23 23:01    [W:4.116 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site