From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
psusi@ubuntu.com
Subject: Re: [linux-lvm] libdevmapper's handling of devices with spaces in the name
Date: Wed, 26 Feb 2014 19:21:40 +0100 [thread overview]
Message-ID: <530E30B4.6020505@redhat.com> (raw)
In-Reply-To: <530E1EA8.9020301@ubuntu.com>
Dne 26.2.2014 18:04, Phillip Susi napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> So if I tell dmsetup to create a device named 'foo bar' it ends up
> actually naming it 'foo\x20bar'. If I run parted on 'foo\x20bar', it
> appears that libdevmapper helpfully tries to unescape the name,
> returning 'foo bar' from dm_task_get_name(). Unfortunately, such a
> dev node does not actually exist so this creates a problem trying to
> open it.
>
> This seems like a bug in libdevmapper. I'd say the name of the actual
> dev node should not be escaped in the first place.
This is no longer true for 'modern' systems with udev.
libdevmapper no longer creates any /dev nodes - it's all job for udev.
And udev has had in dark ages the idea to use 'space' as a separator
for device names in device list. Thus it 'invented' escaping/mangling names.
(There are more prohibited characters which used to be used for normal device
names (see man dmsetup mangling))
If you have system without udev - you could disable name mangling on i.e.
dmsetup cmdline.
There is also envvar DM_DEFAULT_NAME_MANGLING_MODE_ENV_VAR_NAME
which could be used to set prefered behavior.
So there is no bug in libdm side - but I'll not comment on the rest...
I'll just note - it really means all tools now would need to be fixed to
handle udev mangled names properly...
Regards
Zdenek
next prev parent reply other threads:[~2014-02-26 18:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-26 17:04 [linux-lvm] libdevmapper's handling of devices with spaces in the name Phillip Susi
2014-02-26 18:21 ` Zdenek Kabelac [this message]
2014-02-26 18:37 ` Phillip Susi
2014-02-26 19:12 ` Zdenek Kabelac
2014-02-26 20:52 ` Phillip Susi
2014-02-26 21:40 ` Zdenek Kabelac
2014-02-26 22:17 ` Phillip Susi
2014-02-26 23:26 ` Alasdair G Kergon
2014-02-27 8:51 ` Peter Rajnoha
2014-02-27 9:08 ` Peter Rajnoha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=530E30B4.6020505@redhat.com \
--to=zkabelac@redhat.com \
--cc=linux-lvm@redhat.com \
--cc=psusi@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.