umount failing on paths which end in a backslash

umount failing on paths which end in a backslash

[Naja Melan]

I tried to report this bug months ago to the debian maintainers of mount, but debian bug reporting is a minefield and by email all I got was a lousy answer from someone who didn't understand escaping in bash strings and who obviously never ran the script demonstrating the issue. 

Given that this is rather fundamental flaw I decided to post it here. I never tested on anything but debian testing and I don't know if this bug still exists in the latest build.

My version:

mount from util-linux 2.20.1 (with libblkid and selinux support)


The problem is that on ext path names ending in backslash are valid. Mount manages to mount something on them but umount chokes. It looks like somewhere on the way there is an escaping issue.

The following script demonstrates the problem. Obviously you should change cdrom1 to something that exists and that you want to mount.


#!/bin/bash

mkdir 'te\st\'
sudo mount -r /dev/cdrom1 'te\st\'
ls 'te\st\'

echo -e "\n\nmount:"
mount
echo -e "\n\n/proc/mounts:"
cat /proc/mounts
echo -e "\n\numount:"

sudo umount /dev/cdrom1


Abbreviated Output:

...
mount:
...
/dev/sr0 on /media/../te\st\134 type udf (ro,relatime,utf8)
...
cat /proc/mounts:
...
/dev/sr0 /media/.../te\134st\134 udf ro,relatime,utf8 0 0
...
umount: /media/.../te\st\134: not found

Somehow this shows a difference in unescaping between the backslash in the middle and the backslash in the end, which does not get converted back from \134. Note that paths with backslashes in the middle do not suffer from this problem.

Greetings
Naja Melan

Re: umount failing on paths which end in a backslash

[Karel Zak]

On Fri, Aug 10, 2012 at 11:44:35PM +0200, Naja Melan wrote:
> I tried to report this bug months ago to the debian maintainers of
> mount, but debian bug reporting is a minefield and by email all I
> got was a lousy answer from someone who didn't understand escaping
> in bash strings and who obviously never ran the script demonstrating
> the issue.

 Fixed. It seems like a pretty old bug (v2.19 or so...). Thanks!

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com