Re: df enhancment for removable media

[Kevin R. Bulgrien]

Phillip Susi wrote:

> This sounds like an autofs problem.  I'm running ubuntu and hal auto
> mounts removable media when it is inserted.  When it is not mounted, df
> will not show a line for it at all, since df only shows mounted points.
>   I think what you are seeing is an autofs mount point being mounted
> there which is why df shows a line for the mount point, but autofs has
> decided to unmount the real fs and return bogus stat values.
>
> I'd suggest not using autofs.  In any case, this isn't a bug with df.
 
It's not my system, and as an author of a script used by a lot of
people, I don't have a choice about how the system is configured,
but my script has to work anyway.  In this case I do not think it
is autofs.  The example given was from a previous post.  df does
not report a mounted directory in the case I am thinking of.  This
was unheard of for me because the script specifically mounted the
disk.

I didn't say this was a df bug, but I did ask if anything came of
the discussion about working on statfs so that on Suse systems like
this, the df command would do enough so that hal (or whoever) would
properly mount the media enough to get a valid df reading.  Last I
could see on the thread, nobody was disputing that this would be a
good thing.

>>>>> 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.

Sorry, but its just plain weird to have a system dismount media that
you explicitly mounted.  All I am looking for is an idea of the most
sane way to script something so I can get what I want from df on a
system that is configured like the Suse systems that spawned the
thread in the first place.  I just have not encountered this type
of situation before.

Kevin R. Bulgrien