USB disk is automount to "/media/USB DISK" mount point

"USB DISK" is not a string invented by Ubuntu, but rather the volume name of the vfat partition on your USB stick. That said, any spaces really should be replaced by underscores or something..

You are right, "USB DISK" is volume name, created by usb stick manufacturer. I missed that. It will good idea to replace spaces with undercore in such case.

Indeed. Attaced a patch that fixes it.

 status Rejected

This is a feature, not a bug. If a program you use cannot handle
filenames with spaces, please file a bug on that program.

Soren: I think 'principle of least surprise' should apply here. There is
no real need to replace parts of a name a user might expect, so why
should we do it?

On Sun, Jul 30, 2006 at 10:41:04PM -0000, Dennis Kaarsemaker wrote:
> Soren: I think 'principle of least surprise' should apply here. There is
> no real need to replace parts of a name a user might expect, so why
> should we do it?

I really don't think replacing spaces with underscores constitutes a
surprise. If it does, it's a very small one, and spaces in filenames are
just breakage waiting to happen. :-)

spaces in filenames could be real suprise for programmer; it makes design of awk and perl scripts more difficult.

I have to try to put two USB stick with the same volume name to my Ubuntu box. What will happen? The name have to be modified in some way to have unique mount point for every device.

I did experiemnt with two USB sticks with the same volume name. Names are modified as expected, two mount points created, "USB DISK" and "USB DISK-1"

# mount | grep sd[ab]
/dev/sda1 on /media/USB DISK type vfat (rw,nosuid,nodev,quiet,shortname=mixed,uid=1000,gid=1000,umask=077,iocharset=utf8)
/dev/sdb1 on /media/USB DISK-1 type vfat (rw,nosuid,nodev,quiet,shortname=mixed,uid=1000,gid=1000,umask=077,iocharset=utf8)

What a suprise? ;-)

What about Ubuntu applications that cannot handle space in mount point filename? Let's try to find something in Ubuntu 6.06.

Run from GNOME Menu this:
System/Administration/Disks
Select USB disk, switch to partitions tab
Notice "Access path: /media/USB"

Press "browse", you get empty folder. BTW, there is an option (button) to change acess path, when you know what is wrong, you can fix it.

Is more evidence needed that it is easier to fix pmount than most other Linux tools?

I disagree that you have to fix 'most Linux tools'. I do not know any program which doesn't cope with spaces in file names (granted, in shell the escaping is a little inconvenient). If the disk admin tool doesn't, then the bug should be filed against it.

If you convince me that this does affect many programs, then I will change this in pmount. I am just reluctant because I consider spaces an important part of Human language, and it just looks weird and obsolete to not support spaces in file names.

After all, nobody *forces* you to use spaces in file names, and I doubt that many hardware vendors ship their devices with preset labels that contain spaces.

What about this workarround inspired by Windows world. Why to make the mount name based on disk volume name? That is a stupid idea as volume name can be source of trouble (spaces). Take it simple, it will even not confuse windows users (no supprise for user):
/media/A
/media/B
/media/C
etc...

Isn't this smart? ;-)

BTW, I created bug agains GNOME Disk Manager, bug #54758.

On Tue, Aug 01, 2006 at 09:00:27AM -0000, psl wrote:
> /media/A
> /media/B
> /media/C
> etc...
>
> Isn't this smart? ;-)

No. It suffers from the same complete lack of information about the
device hidden behind the mount point making it REALLY annoying to find
the mount point you're looking for.

On Tue, Aug 01, 2006 at 05:03:00AM -0000, Martin Pitt wrote:
> I disagree that you have to fix 'most Linux tools'. I do not know any
> program which doesn't cope with spaces in file names

make?

Hi,

Soren Hansen [2006-08-01 9:42 -0000]:
> On Tue, Aug 01, 2006 at 05:03:00AM -0000, Martin Pitt wrote:
> > I disagree that you have to fix 'most Linux tools'. I do not know any
> > program which doesn't cope with spaces in file names
>
> make?

Example?

It works pretty well for me:

--- snip: Makefile ---
foo\ bar:
        @echo Hi
--- snip: Makefile ---

$ make 'foo bar'
Hi

On Wed, Aug 02, 2006 at 09:59:42AM -0000, Martin Pitt wrote:
> > > I disagree that you have to fix 'most Linux tools'. I do not know
> > > any program which doesn't cope with spaces in file names
> > make?
> Example?
>
> It works pretty well for me:
>
> --- snip: Makefile ---
> foo\ bar:
> @echo Hi
> --- snip: Makefile ---

You're not actually dealing with file names with spaces in them, but
rather just make targets with spaces in them.

-- snip: Makefile --
%:%.c
 $(CC) $(CFLAGS) -o "$@" "$<"
-- snip: Makefile --

-- snip: hello_world.c --
#include <stdio.h>

int main(int argc, char **argv)
{
    printf("hello, world\n");
    return 0;
}
-- snip: hello_world.c --

$ make hello_world
cc -o "hello_world" "hello_world.c"

No problem, but:

$ cp hello_world.c hello\ world.c ; make hello\ world
make: *** No rule to make target `hello world'. Stop.

I add a software not working with space in filename.
/etc/init.d/umountfs

for example the live CD is mounted as:
/media/Ubuntu\ 07.04\ ppc
with in /proc/mounts
/dev/hdc /media/Ubuntu\0407.04\040ppc iso9660 ro,nosuid,nodev,noexec...

On reboot/shutdown umountfs doesn't get the quoting right and executes
umount /media/Ubuntu0407.04040ppc

Last but not least \0407 is not compatible with /bin/echo -e

With a rw fs we are speaking of data corruption here.

Even "scp" cannot handle spaces in filenames correctly:

$ touch "test file"
$ mkdir test_dir

$ scp test\ file test_dir/
cp: cannot stat `file': No such file or directory

$ scp "test file" test_dir/
cp: cannot stat `file': No such file or directory

$ touch test_file
$ mkdir "test dir"

$ scp test_file test\ dir
cp: `dir': specified destination directory does not exist
Try `cp --help' for more information.

$ scp test_file "test dir"
cp: `dir': specified destination directory does not exist
Try `cp --help' for more information.

scp handles them just fine on my computer:

$ touch "test file"
$ mkdir test_dir
$ scp test\ file test_dir
$ mkdir "test dir"
$ scp -r test_dir test\ dir
$

closed - due its a feature-request and need's a new look after this time..

it has been rejected eariler and end's up in exhausting discussios..