Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 30 Nov 2010 09:36:50 -0800 | From | Greg KH <> | Subject | Re: odd behavior from /sys/block (sysfs) |
| |
On Sat, Nov 27, 2010 at 04:14:11PM -0500, Michael Richardson wrote: > > >>>>> "Greg" == Greg KH <gregkh@suse.de> writes: > >> {please CC me} > >> > >> I was capturing data from my laptop's /sys file system as test input > >> for some code that needs to grovel through /sys a bit. I found it weird > >> that tar got different answers than ls! See below (at end) for original > >> observation. > >> > >> It seems that this is because lstat64() on sysfs returns st_size=0 for > >> the link, and tar does not know how to deal with this, while ls does. > >> I don't know if it is tar that is wrong, or sysfs. > >> lstat64(3) suggests that it is sysfs that is at fault, that it should > >> set st_size. The behaviour of ls, suggests that perhaps other systems > >> have worked around st_size=0 for symlinks. (I'm on 2.6.32-bpo.5 > >> from debian) > > Greg> So, what do you think should be changed here? > > Iif st_size=0 is not a valid return from readlink(2), then I think sysfs > should be fixed. I will cook a patch. > > While tar might not useful (I was successful at using cp -r, btw), > having working file operations makes sense.
I agree, a patch would be most welcome.
> Greg> I wouldn't ever recommend using tar on sysfs as it doesn't make any > Greg> sense (sysfs is a virtual file system, like /proc/ and I think > Greg> that tar doesn't like /proc either, right?) > > Are there things on /sys for which a read is not idempotent?
There might be some binary files in /sys where this does not happen.
Also note that other filesystems are mounted under /sys, like debugfs which is in /sys/kernel/debug/ and all bets are off as to what are in those files and if they ever terminate :)
thanks,
greg k-h
| ![\](/images/icornerr.gif) |