ZFS and filenames with a leading space - dropping the leading space

[Primož]

So i have (luckily) just a few files, that for some reason start with a leading space before the actual alphanumeric sharacters start being used. These files being torrents, i couldn't figure out why my torrent client didn't recognize them when checking. I did notice there's a difference in a leading space character between the original files (on a NTFS drive) and the files on my ZFS pool, but didn't put much thought into it and figured i somehow copied over a diferent folder or something along those lines.

Copying the files again just now, i noticed that as soon as they are copied to the ZFS pool, the leading space gets dropped.

Is anyone able to tell me why this happens? Could this be related to the case (in)sensitive setting of the dataset?

 

[Chris Moore]

I don't think a leading space is legal use for file names

Sent from my SAMSUNG-SGH-I537 using Tapatalk

 

[Primož]

Wouldn't be surprised if that is indeed the case, but on the other hand it is possible in some cases, so shouldn't there be provision to take care of it?

It's not a huge issue, i'd just like to understand it.

 

[jgreco]

I don't think a leading space is legal use for file names

Sure it is. UNIX disallows precisely two characters, "/" and NUL, in filenames. The "/" because that's the separator for pathnames, and NUL, because, well, UNIX uses that all over to represent end-of-string.

Try it: run the command

# touch " "
# ls -al
total 4
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:39
drwxr-xr-x 2 jgreco wheel 512 Jan 14 07:39 .
drwxrwxrwt 8 root wheel 512 Jan 14 07:39 ..

Whether or not it is a good IDEA to name files with unusual characters, that's another issue. Naming a file with a leading "-" is problematic for argument interpretation.

> touch ./- ./\* ./\? ./\& ./\$ ./\\ ./\" ./\' ./@ .\#
> ls -al
total 4
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:39
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 "
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 $
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 &
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 '
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 *
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 -
drwxr-xr-x 2 jgreco wheel 512 Jan 14 07:41 .
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 .#
drwxrwxrwt 8 root wheel 512 Jan 14 07:40 ..
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 ?
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 @
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 \

A whoops, I even made a mistake there and it still worked. "Find the mistake." ;-)

 

[jgreco]

Wouldn't be surprised if that is indeed the case, but on the other hand it is possible in some cases, so shouldn't there be provision to take care of it?

It's not a huge issue, i'd just like to understand it.

It's probably a matter of how you copied it. It's pretty easy for tools to not be able to handle all the edge cases, especially since you probably used a Windows tool to do the move.

Ah yes.

It's the Windows tool.

From your Windows, do

C:\Users\you\Desktop> echo foo > " foo"
C:\Users\you\Desktop> \cygwin\bin\mv " foo" X:\

and the file copies fine with the leading space. Repeat with the Windows GUI mover and it breaks. Thanks, Mickey-soft.

 

[Primož]

Good to find the issue and even better that it's not an issue of FreeNAS or ZFS :)

Thanks for the help!

 

[Chris Moore]

Wouldn't be surprised if that is indeed the case, but on the other hand it is possible in some cases, so shouldn't there be provision to take care of it?

It's not a huge issue, i'd just like to understand it.

It looks like the underlying filesystem in Windows doesn't mind having a leading space as a file name, but most of the applications will discard a leading space for some reason. It is like the people writing the software at Microsoft are intentionally killing the space. It probably is an old bit of standard code that they use by reference.

 

[Primož]

FYI, i tried changing the names on the network share and instantly, as you press enter to confirm, the leading space disappears. I tried it by copying the file to the desktop and the behaviour stays the same, the leading space disappears on confirmation as well.

I did manage to add leading spaces with a renaming utility on the share, so this is 100 % confirmed Windows environment issue.

 

[Chris Moore]

Sure it is. UNIX disallows precisely two characters, "/" and NUL, in filenames. The "/" because that's the separator for pathnames, and NUL, because, well, UNIX uses that all over to represent end-of-string.

I didn't mean in Linux / Unix. I was talking about Windows. You can force the creation of a filename with a leading space from the command line, but there appears to be no way to do that from within a Windows application, but my testing was not extensive.

 

[jgreco]

I didn't mean in Linux / Unix. I was talking about Windows. You can force the creation of a filename with a leading space from the command line, but there appears to be no way to do that from within a Windows application, but my testing was not extensive.

Well we could just say Windows sucks and call it a day ;-) ;-)

 

[Linkman]

> touch ./- ./\* ./\? ./\& ./\$ ./\\ ./\" ./\' ./@ .\#
> ls -al
total 4
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:39
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 "
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 $
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 &
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 '
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 *
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 -
drwxr-xr-x 2 jgreco wheel 512 Jan 14 07:41 .
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 .#
drwxrwxrwt 8 root wheel 512 Jan 14 07:40 ..
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 ?
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 @
-rw-r--r-- 1 jgreco wheel 0 Jan 14 07:41 \

A whoops, I even made a mistake there and it still worked. "Find the mistake." ;-)

That one?

 

[jgreco]

Yeah, too many slishyslashes and my brain fried, or fingers couldn't take it, don't know which.