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 <address@hidden> 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.