Your original bug request said: "e2label lets you use any character,
including / or * or $ ( and probably others, like accented letters é è à
)..... it should not be possible to use those in label names."   You've
now backpedaled and said, "I never said that!  Only "risky" characters!"

"Risky" as defined by whom?    In your example, lsblk and e2label
displayed the label without a problem.   Who cares if you needed to use
a backslash to protect the "$" or "*" or " " characters?  They look just
fine.  And if the argument is that space character is well managed by
auto-completion in most CLI "mostly", I'll note that so is the "*"
character.  For example:

% touch qfoo\*bar
% ls qf<tab>

... and bash will expand that to "qfoo\*bar" so it works just **fine**
with bash.   I've just checked and the completion function used in ksh,
tcsh, and emacs (which does not require any quoting so that's a gimme)
means that it works just fine.   So any argument that you use for
outlawing * in labels would apply to spaces, too ---- and if for labels,
why not filenames?   Shouldn't filenames be "robust" and "foolproof"?
By some unknown definition of "fool"?

Going back to labels ---- for the most part, labels are mostly used for
display purposes, so if someone happens to create a label with a ' ',
'*', or '$' character, it's not a big deal; lsblk, blkid, etc. will
display them just fine.   And no escaping is necessary if you put a
special character in /etc/fstab.  For example, the following works in
/etc/fstab:

LABEL=foo$bar /mnt ext4 defaults 0 0

Sure, some care might be needed to *set* the label to "foo$bar" --- you
might need to type "e2label /dev/loop0 'foo$bar'" --- but the quoting
rules are enforced by the shell.  It might be some other shell might not
use "$" for variables --- or there might be a disk management GUI which
doesn't use quoting, just as emacs and Libreoffice doesn't require
quoting for file names with spaces in it.   So setting some arbitrary
rule because of the interface that the user might be using doesn't make
any sense.   If the user is smart enough to figure out how to pass
'foo$bar' to e2label, we should let them use it.  Why should we print
some kind of nanny-state, "naughty, naughty!  you did something that
might confuse a less clueful user!!" warning.

Again, the standard that said we should do that for labels would also
apply to characters, and then I will have *other* launchpad users
complaining to me about why did I set some kind of arbitrary
restriction, and that they had a perfectly good reason for wanting to
use these characters in their label or their filenames.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/2027979

Title:
  won't warn neither prevent usage of « risky » characters in labels

Status in e2fsprogs package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  if naming or renaming an EXT volume,

  e2label lets you use any character, including / or * or $ ( and
  probably others, like accented letters é è à )

  I'd expect at least a warning if such are to be found in a label name.

  Or better, it should not be possible to use those in label names.

  Example :

  a@p:~$ sudo e2label /dev/sdb12 /Ti\$*
  a@p:~$

  a@p:~$ sudo e2label /dev/sdb12
  /Ti$*
  a@p:~$

  a@p:~$ lsblk -fe7 | grep sdb12
  └─sdb12   ext4              1.0   /Ti$*             
f583e9b0-f1de-438f-8da8-c1e070407628
  a@p:~$

  coming from https://forum.ubuntu-
  fr.org/viewtopic.php?pid=22692892#p22692892 ( french )

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2027979/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to