Re: df enhancment for removable media

[Kevin R. Bulgrien]

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.