Hi. There's an annoying problem with device-mapper. The background is here: https://bugs.archlinux.org/task/23184 .
ntfs-3g adds "/dev/dm-*" entries to mtab instead of "/dev/mapper/*". Such filesystems can be unmounted only by the mount point name, but not the device name.
It mostly affects the truecrypt users.

This problem is present in current git. It would be great if the developers picked the attached patch. In it I replaced all usages of realpath() function to it's analog from the util-linux project, that correctly handles /dev/dm-* names.
On other OSes all should work as before.

Hi,



Hmm. This problem is unrelated to ntfs-3g, you have to patch all the filesystems drivers (at least all which rely on fuse).

First, can you check that the modification to "mount_util.c" is unneeded, this deals with the mountpoint, not the device path.

Then, I see that ntfs-3g forwards the device path it receives to fuse, which forwards to some package which puts it into mtab. Do you know where the "dm-*" comes from, and why umount cannot use it ? Either a wrong path has been issued or it should be usable by its targets, ntfs-3g is just a way among others from the source to a target.

Or am I missing something ?

Regards

Jean-Pierre

mount/umount have their own funtion to canonicalize device file names. Perhaps, there're 2 reasons:
Sometimes (with dmraid) /dev/mapper/* files can be NOT symlinks to /dev/dm-*, but special files with the same major:minor.
/dev/mapper/* names are quite descriptive compared to dm-0, dm-1 etc.

The umount program expects the canonic device name in mtab (or --no-canonicalize). Otherwise it'll fail.
Truecript expects /dev/mapper/truecrypt*, when it checks whether it's volumes are mounted.


This issue seems common among drivers that use their own mount program, e.g. nilfs2. They use realpath() to resolve symlinks. If you change it, this issue will vanish in modern linuxes. Older linuxes won't be affected.


Is libfuse-lite only for linux, where we shouldn't check for presence of realpath()?

Hi,



libfuse-lite is a simplified fuse library. Some distributions use it, others (eg Ubuntu) use the full fuse library. If you need fixing fuse-lite, you also need fixing the full version.

However, your explanation is only about the device path, and the realpath() in fuse is about the mountpoint, NOT the device path, so the part of your proposed patch dealing with the file libfuse-lite/mount_util.c is not related to the issue. I just would like you to remove this part and check whether the fix is still valid. I just have no configuration to make sure of it.

Regards

Jean-Pierre

I understood that _ntfs_canonicalize_path() shouldn't be used inside libfuse-lite, but there's also _ntfs_realpath() - a dummy realpath() implementation for systems lacking it.
I mean, is there a possibility that libfuse-lite will be used on a system without realpath()? Then we should keep realpath.c inside libfuse-lite. Otherwise I can move it to libntfs-3g.

Hi again,


But that is not what I mean. The realpath() at line 180 of mount-util.c has nothing to do with /dev/anything, it is not related with your issue. You should leave it unchanged, no need to move it elsewhere.

Regards

Jean-Pierre

Sorry for the delay. Heres the patch without mount-util.c

Hi,


Thanks. Can you confirm this fixes your issue ? I cannot test myself.

Also, is there a real need for "#define MAXSYMLINKS" ?

Regards

Jean-Pierre

i confirm.
Yes, MAXSYMLINKS is unneeded - leftover code.

-

I ran into this recently on Ubuntu during the Natty development cycle when it caused the installer to hang. There are two related bugs, one in umount, and one in ntfs-3g. The bug in umount is that even when you specify the dm-N name that is recorded in mtab, it fails to unmount it. I reported this to the util-linux mailing list where it was fixed. The bug in ntfs-3g is that it records dm-N instead of /dev/mapper/foo in mtab. It needs to record the /dev/mapper/foo name so that you can later unmount the same device name that you used to mount with.

This applies to dmraid devices, but also LVM, though it is unlikely that people will be using NTFS on an LVM volume since it isn't accessible to Windows.

Hi,


Can you check whether the patch posted above by basinilya solves this ?

My interpretation is that this is the only bug. When you mount a symlinked device, such as /dev/disk/by-uuid/xx, the actual device path is stored in mtab, and umount is able to unmount the symlinked name. It should be able to unmount dm-N names the same way. You are not to patch all filesystems as a workaround. AFAIK the canonicalization is made to prevent device hijackings.

This is probably the same as the patch posted by basinilya.

Do you mean the same patch applies, or a similar workaround is also needed ?

Regards

Jean-Pierre

The /dev/mapper/name is the canonical device name, not a symlink. Quoting the discussion from util-linux:

The /dev/dm-N names are private for DM and should not be used in
userspace for normal operations. All utils which use the /dev/dm-N
format for DM devices (in output or in files like mtab) should be
FIXED.

Karel



I mean the same problem applies because LVM is also a device-mapper device.