Page 2 of 2

Re: Spaces in paths & filenames

Posted: Sun Oct 01, 2017 1:46 pm UTC
by Mutex
I discovered this after finding out the reason a program wouldn't load the right settings file was the file had a space at the start of its name (which shouldn't have been there), and thinking "wtf, that's allowed?"

Re: Spaces in paths & filenames

Posted: Sun Oct 01, 2017 4:28 pm UTC
by Soupspoon
Mutex wrote:In Windows, you need to do this through a terminal emulator (Git Bash worked for me), Windows Explorer won't allow you to create them, and actually throws an error if you try deleting them! So, fun prank potential there obviously. The Linux file manager I tried allowed both creation and deletion.

I don't have any 'terminal emulator' other than the terminal emulator, arguably, that is cmd.exe. I can md " spaces" and echo Hello > " spaces.txt" or notepad " loadsofspaces.txt" (ironically, which doesn't survive HTML rendering for the number of consecutive spaces it actually has) which can be then be saved, but see later.

I can do this all I like and get absolutely no problem, nor any problem with deleting or renaming them in any file explorer (including load/save dialogues), except that they shave off and throw away any leading whitespace when renaming (or using the "Save as", from notepad/etc, but just Ctrl-S saving as the provided name after starting up with "Cannot find the. loadsofspaces.txt file. Do you want to create a new file?" retains the given whitespace-leader). I haven't yet managed to provoke an error being thrown, just silent "You obviously didn't mean all those spaces" when I let the non-DOS tools mess with them. (c.f. ren " 1leadingspace.txt" " 2leadingspaces.txt" working as imagined, but F2 on the file sanitising the spaces away.)

DIR /X shows that the SFN is SPACES~1.TXT (or similar) alongside the space-prefixed LFN. Could it be your Git Bash that isn't accessing one or other of the LFN/SFN portiins of the FAT table properly, thus tripping up explorer.exe and its derivatives when dealing with more unstandardised stuff?

Re: Spaces in paths & filenames

Posted: Sun Oct 01, 2017 4:57 pm UTC
by Mutex
Did you try it with a filename that is literally just one or more spaces and nothing else? I don't have an instance of Windows handy right now.

Re: Spaces in paths & filenames

Posted: Sun Oct 01, 2017 10:10 pm UTC
by chridd
Mutex wrote:I discovered this after finding out the reason a program wouldn't load the right settings file was the file had a space at the start of its name (which shouldn't have been there), and thinking "wtf, that's allowed?"
It surprised me more the first time I found out a system didn't support it. Why would a system or program arbitrarily disallow some possible combinations of characters in a filename?

Re: Spaces in paths & filenames

Posted: Sun Oct 01, 2017 11:51 pm UTC
by Thesh
Developers running trim() on all user input is not unheard of.

Re: Spaces in paths & filenames

Posted: Mon Oct 02, 2017 12:45 am UTC
by Soupspoon
Pure whitespace-only (well, space-only, as tab autocompletes, and CR and/or LF is as tricksy) provokes "The system cannot find the path specified." upon echo-redirecting attempts. (Notepad-opening with quoted spaces-only appends the "missing" .txt extension, which then allows it in exactly the ways already mentioned.)

Going further, any sort of /^\s*\.\s*$/ pattern that is not NE literal-dot returns "Access is denied." as if I had tried just tried to echo to the current working directory and MD " . " tells me that it already exists (the error message retaining all the space-padding around the dot, so you get "A_subdirectory_or_file_<initialspaces>.<finalspaces>_already exists.", here substituted by two notations for your dissemination only), yet if I use it as a DIR param it spends time thinking about it and then giving a File Not Found much like DIR "DoesNotExist.FIL" would, rather than giving the obvious result of DIR "."… So a possibly interesting start to a fuller black-box investigation of where the DOS subsystem does its sanitising.

(ETA: MD " X . Y ", i.e. space-padding before and after name and extension components, gives something that Explorer displays as spaceXspace.spaceY(no space), and DIR > file and notepadding the file also confirms the trailing extension space is absent at that level. And a further MD without trailing space complains about it already existing, as does any of the obvious methods for FOR-grabbing and processing, to dispell the suspicion that it was some form of pre-filtered output that rendered legitimate trailing spaces as absent. Either that, or it's additionally arranged with exceptional checks to ensure no many-to-one/one-to-many file-label confusion occurs. None of these constructions, once created, resist deletion by explorer. Not shift-deletion, anyway. I have not yet tested the more usual vanilla deletion and see what problems transfering to Recycled Bin might invoke, out of habit...)


I can well believe that in the apparent absence of the normal m/^\s*$/ pre-exclusion, the Git Bash thing can do something unexpected (not even "we think we know what you mean, so doing that for you") to the file list. I suppose a bit like you can(/could) occasionally create 'unspecial special-files' CON or PRN or whatever to break things with the 'right' methods.


That was fun, though. I may try these things on different Windows versions' DOSes to see if/when there have been changes (98, 2K, XP and up to 8 should be at hand, and probably DOS ~6.22ish as well, tomorrow, if I remember).