[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xreadlink.c initial buffer size guesstimate
From: |
Liyang HU |
Subject: |
Re: xreadlink.c initial buffer size guesstimate |
Date: |
Sat, 13 Jan 2007 23:48:56 +0000 |
User-agent: |
Mutt/1.4.1i |
On Fri, Jan 12, 2007 at 08:30:24AM -0700, Eric Blake wrote:
> why should you expect sane behavior from tools that assume POSIX?
If xreadlink() assumed POSIX, it would allocate a fixed buffer of 256 bytes.
> By violating that rule of POSIX, the bug is squarely on your FS's shoulders,
I'm not even sure my toy FS violates POSIX. st_size contains the /on-disk/
size of the symlink, not the length of the symlink in bytes. It's the latter
value xreadlink() wants; the former may very well be a gross overestimate.
And it just so happens to be in this case.
Claiming a 93B symlink takes 300MB on-disk: Pathological? Certainly. I'm not
convinced that's a violation of any rules though.
> an uphill battle because it will be more than ls that are affected.
*shrug* Few programs actively check for symlinks, never mind lstat()ing
them. In practice it works very well. :)
Regardless of whether my toy FS is broken, xreadlink should behave in a more
robust matter. That's all I'm saying.
Cheers,
/Liyang
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.