After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 149977 - G-V-M should resolve symlinks in fstab before attempting mount
G-V-M should resolve symlinks in fstab before attempting mount
Status: RESOLVED NOTABUG
Product: gnome-volume-manager
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Robert Love
Robert Love
: 153767 155637 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-12 16:58 UTC by Jerome Haltom
Modified: 2006-08-01 15:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to resolve device in fstab (2.71 KB, patch)
2004-08-12 18:28 UTC, Jerome Haltom
none Details | Review

Description Jerome Haltom 2004-08-12 16:58:54 UTC
If a link exists in fstab, such as /dev/cdrom, instead of the actual path,
/dev/hdc or something, g-v-m will not mount it. It just runs the mount command
followed by the device it detected the event on, which fails.
Comment 1 Jerome Haltom 2004-08-12 18:28:23 UTC
Created attachment 30479 [details] [review]
patch to resolve device in fstab

Here is a patch to "fix" this behavior. It uses the "mntent" API. It's fairly
simple. Upon calling gvm_mount_device, the device is matched against each entry
in the fstab file, resolved to it's realpath. If the device matches, it is
returned to gvm_mount_device.

I wanted to return proper GErrors, so I created a GQuark for the domain at the
top of the new function. This is not right, but I'm leaving that up to somebody
who knows what they're doing. ;0
Comment 2 Robert Love 2004-09-18 17:17:31 UTC
Patch is fine, but what is the big deal with just forcing the user to have the
right entry in fstab?  Besides, the actual fix is in mount(1) not g-v-m.

Anyhow, if HAL manages your fstab, it is not a problem.
Comment 3 Jerome Haltom 2004-09-18 18:18:39 UTC
You're right. However, many distros (Debian of the top of my head) by default
put /dev/cdrom, or another similar symlink, in fstab.

Also, the world not being perfect, some people might not want HAL to be editing
this file for them. Do we simply force those people to alter their file manually
before it works?

I would go for a dual approach. First off, HAL *should* put the correct entries
in this file. And second, GVM should work in both cases.
Comment 4 Robert Love 2005-02-01 05:58:22 UTC
*** Bug 153767 has been marked as a duplicate of this bug. ***
Comment 5 Jaap A. Haitsma 2005-04-27 21:02:31 UTC
In debian symlinks now work OK, but the debian maintainer applied some extra
patches. So it might be that
Comment 6 Jeffrey Stedfast 2005-06-27 21:00:05 UTC
this patch can no longer be applied to CVS due to some of my recent changes...
anyway, it shouldn't fail simply because the device wasn't in /etc/fstab - it's
possible the mount could still work (especially with my latest changes that
allow setting the mount command at compile-time).

overall, though, I agree with Rob that this should really be fixed in mount (or
just fixing /etc/fstab) and not g-v-m. Having to parse /etc/fstab just feels
dirty to me.
Comment 7 Jeffrey Stedfast 2005-06-27 21:08:52 UTC
*** Bug 155637 has been marked as a duplicate of this bug. ***
Comment 8 Jeffrey Stedfast 2005-07-18 18:44:17 UTC
closing as not a bug in g-v-m
Comment 9 Jaap A. Haitsma 2005-07-18 18:51:16 UTC
Why is it not a bug?
IMHO opinion it would be better that gvm solves this instead of every maitainer
for a distro that has symlinks for certain devices.
Comment 10 Mantas Kriaučiūnas 2006-08-01 15:26:03 UTC
It seems this is gnome-vfs2 bug, so please don't resolve as NOTABUG, but reassign to gnome-vfs2