10:17 a.m.
I'm running the current Rawhide FC5 and have been looking at device
detection issues and mounting.
I earlier mentioned a problem with Konqueror where is would mount a floppy
drive multiple times and not be able to unmount it. It looks like the
problem might be that HAL does not delete the mount point in /media after
unmounting, the mount points just pile up. With other devices, such as
USB flash drives, unmounting results in deletion of the mount point.
Another troublsome situation arises when a USB drive is attached at boot
time. In that case, the device is mounted but root seems to own the
device and the user is unable to umount it. Is this intentional?
||||| William Shotts, Jr. (bshotts AT panix DOT com)
||||| Be a Linux Commander! Follow me to http://linuxcommand.org
||||| See my photography! http://www.williamshottsphotography.com
10:42 a.m.
On 2/19/06, William Shotts <bshotts(a)panix.com> wrote:
Another troublsome situation arises when a USB drive is attached at
boot
time. In that case, the device is mounted but root seems to own the
device and the user is unable to umount it. Is this intentional?
I'm not seeing this behavior on my system. Is there an fstab entry
that corresponds to that device on your system. There shouldn't be..
but if there is that could explain the root owned automount that's
happening before desktop login.
-jef
11 a.m.
On 2/19/06, William Shotts <bshotts(a)panix.com> wrote:
> Another troublsome situation arises when a USB drive is attached at boot
> time. In that case, the device is mounted but root seems to own the
> device and the user is unable to umount it. Is this intentional?
I'm not seeing this behavior on my system. Is there an fstab entry
that corresponds to that device on your system. There shouldn't be..
but if there is that could explain the root owned automount that's
happening before desktop login.
No, there are no such entries in fstab, however another thing I just
discovered is that the problem does not affect all USB devices. The
problem seems not to occur with my USB flash drive but does affect my
120GB USB hard disk. After reboot and login media looks like this:
[bshotts@twin7 ~]$ ls -l /media
total 20
drwxr-xr-x 2 bshotts root 16384 Dec 31 1969 disk
drwxr-xr-x 4 root root 4096 Feb 18 16:04 usb-ext3
"disk" is a 16MB USB pen drive and "usb-ext3" is the hard drive.
||||| William Shotts, Jr. (bshotts AT panix DOT com)
||||| Be a Linux Commander! Follow me to http://linuxcommand.org
||||| See my photography! http://www.williamshottsphotography.com
11:05 a.m.
On 2/19/06, William Shotts <bshotts(a)panix.com> wrote:
No, there are no such entries in fstab, however another thing I just
discovered is that the problem does not affect all USB devices. The
problem seems not to occur with my USB flash drive but does affect my
120GB USB hard disk. After reboot and login media looks like this:
I have a usb 240GB harddrive but its vfat formated that doesn't have this issue.
-jef
11:20 a.m.
I have a usb 240GB harddrive but its vfat formated that doesn't
have this
issue.
-jef
I just replaced the ext3 formatted drive with a vfat formatted drive and
the problem did not occur, so vfat is immune while ext3 is not.
||||| William Shotts, Jr. (bshotts AT panix DOT com)
||||| Be a Linux Commander! Follow me to http://linuxcommand.org
||||| See my photography! http://www.williamshottsphotography.com
11:35 a.m.
On 2/19/06, William Shotts <bshotts(a)panix.com> wrote:
I just replaced the ext3 formatted drive with a vfat formatted drive
and
the problem did not occur, so vfat is immune while ext3 is not.
well then... the question is.. is this broken behavior or a feature?
since ext3 supports multiuser permissions it could be delibrate
detection on bootup.. or it could be an oversight since the common
scenario is vfat for per-user attached storage.
Seems like a bug to me.
-jef
11:59 a.m.
well then... the question is.. is this broken behavior or a feature?
since ext3 supports multiuser permissions it could be delibrate
detection on bootup.. or it could be an oversight since the common
scenario is vfat for per-user attached storage.
Seems like a bug to me.
-jef
I agree. Seems like an oversight.
I notice also that if the volume is present at boot time, it is given a
different mount point name (some variation on "disk") than when it is
hot-plugged (volume name). While this volume name/mount point issue has
been discussed extensively on this list, there are a few things I would
like to say about it.
First, as a CLI user, the use of volume names for mount points is clearly
annoying but I'll live with whatever decision is made.
However, I am concerned that the volume name scheme is not consistently
applied (see above) and perhaps more importantly, it appears contrary to
the FHS. It is my belief that, all things being equal, the decision
should lean towards standards.
My 2 cents.
||||| William Shotts, Jr. (bshotts AT panix DOT com)
||||| Be a Linux Commander! Follow me to http://linuxcommand.org
||||| See my photography! http://www.williamshottsphotography.com
12:06 p.m.
On 2/19/06, William Shotts <bshotts(a)panix.com> wrote:
I notice also that if the volume is present at boot time, it is given
a
different mount point name (some variation on "disk") than when it is
hot-plugged (volume name). While this volume name/mount point issue has
been discussed extensively on this list, there are a few things I would
like to say about it.
Something is definitely odd about the boot-time versus post-boottime
behavior which needs to be addressed. I can't see a good argument for
a difference in behavior like that. That would explain why I dont see
the volumename mounts that other people are complaining about. The
whole point of using the volumename is sort of defeated if its not
consistently applied with regard to when in time the device is present
on the system.
This is most definitely a filable if no one has filed it yet.
-jef"and it looks to me that there is plans afoot to provide a way for
users to override the volumename scheme on a per-user basis, look at
the ui tool gnome-mount-properties for a glimpse at what is to
come"spaleta
6634
days inactive
6634
days old
7 comments
2 participants
participants (2)
-
Jef Spaleta -
William Shotts