Did anything final every come out of this thread. I've written a plug-in script for amaroK that a Suse user is complaining about. I never heard of a system unmounting a disk automagically behind the user's back when a mount was explicitly requested.
df is reporting USB media to be have 0 bytes free. The simple ls /media/USB_DISK >/dev/null; df /media/USB_DISK example is not sufficient to get df to report something real. Does anyone feel like giving some idea how this might best be handled. I hate to kludge things by creating a file on the USB device, and it seems silly to over-access the media just to get a df to output what I want. I could do a find, because some other function in my script does that and df reports properly, but it seems pretty heavy-handed for a simple space check to run through a USB drive that might be a few GB in size with hundreds of files. Is this something that was "fixed" so that a later version of Suse might have a df that works? If so, I might just allow the user to override the space checking in the event he has an affected system. Thanks, Kevin R. Bulgrien Juergen Weigert wrote: > Hi coreutils people! > > On a recent SUSE Linux df became unreliable for e.g. USB-drives. > This is because hald automatically mounts and unmounts such drives > as they are accessed. > > Usually I get something like: > > $ df /media/USB_DISK > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 0 0 0 - /media/USB_DISK > > only if the USB_DISK is being accessed, I get the expected output. > > $ ls /media/USB_DISK > /dev/null; df /media/USB_DISK > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 252522 238718 13804 95% /media/USB_DISK > > A simple enhancement for df is to actively access the USB_DISK while > running statfs(). I've added an opendir() call in the attached patch. This > can be suppressed with a new commandline option -n. > > Please keep me in CC, I am not subscribed. > > thanks, > Jw. Paul Eggert wrote: > Juergen Weigert <[EMAIL PROTECTED]> writes: > >>> Unless I'm missing something I'd rather not change the default behavor >>> of df, as that would be a compatibility hassle. That is, df shouldn't >>> attempt to mount file systems by default; it should do so only if the >>> user asks, with a new option. >> >> These hald mounts are different. For almost every aspect such a device >> appears to be mounted. So I figured, df should also pretend the >> device is mounted. > > But lots of programs other than df invoke statfs. We shouldn't have > to change them all. Instead, it would be much better to fix statfs to > do the right thing with hald mounts. statfs should return values that > are consistent with every other system call: it should not return > incorrect values simply for the convenience of some low-level hardware > abstraction layer. > > Please also see the message from Ivan Guyrdiev of Cornell archived at > <http://www.nsa.gov/selinux/list-archive/0507/thread_body36.cfm> dated > 2005-07-20 in which he says something similar: the statfs > implementation needs to get fixed. > > >> Looks ugly in df.c, right. But in fsusage.c we'd have to place the >> new code in multiple implementations. Ugly too. > > It would only need to be placed in sections corresponding to > implementations that have the bug. Currently, that's just one > implementation: GNU/Linux, and only a small subset of these hosts as > well. Since the workaround issues more system calls, it would be nice > to detect the broken implementations at compile-time somehow, or at > least filter out the obviously non-broken implementations. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
