5 ms·
> While we’re on the topic, it’s worth noting that the only other restriction on filenames is that that they cannot contain a /, which is the character used to
by ChrisSD 7y ago
> While we’re on the topic, it’s worth noting that the only other restriction on filenames is that that they cannot contain a /, which is the character used to denote directories. Filenames can contain arbitrary other binary data, including spaces and newlines, and there’s no defined character encoding.
I've seen this byte people when junk gets written to a filename (either accidentally or maliciously). Especially in shells but also in other programming languages. Issues that aren't always handled well include file names that:
* include a newline or some other control characters
* start with a `-`
* aren't valid UTF-8
- heavenlyblue 7y agoI have recently accidentally created a folder named “~”. Then I tried deleting it through shell.
- NullPrefix 7y agoYou can "safely" delete it with non-recursive rmdir
- bhaak 7y agoDeleting a dir with rmdir is always safe :-) The other trick that makes dangerous operations always more safe is prepending "./" to the path.
- smichel17 7y agoI did similar, once. I had a script where I misquoted and ended up with a directory starting with ~ It was the only directory starting that way, so I typed "rm -rf ~<TAB><ENTER>" Hit control-C a half second later, but the damage was done. Fortunately most of my important files are backed up. Lesson: when deleting files with tricky names, write the command without flags first, then add "-rf" after the path is confirmed correct.
- heavenlyblue 7y agoI’ve got lucky with some directory that is called .asound or similar. It was the first one in the home directory and it didn’t manage to go beyond that.
- naedish 7y agoAren't the filenames . and .. also restricted in Unix? Windows has many more restrictions. [1] [1] https://kizu514.com/blog/forbidden-file-names-on-windows-10/ https://kizu514.com/blog/forbidden-file-names-on-windows-10/
- ChrisSD 7y agoNote that "forbidden" filenames only apply to win32 paths. "Extended-length" paths can be used to create and open such files. This can cause issues with applications that don't know how to handle them. But yes, Windows reserves (16 bit encoded) ASCII control characters and some special symbols like question mark and colon. As for . and .. I believe that on UNIX they are just symlinks, though they may be treated specially by applications? On Windows they don't really exist but some APIs emulate them when resolving paths.
- cesarb 7y ago> As for . and .. I believe that on UNIX they are just symlinks, though they may be treated specially by applications? No, they are treated specially by the kernel and/or the filesystem. They behave similar to hardlinks to the corresponding directory (hardlinks to directories aren't allowed nowadays, these two are an exception). The special treatment by applications is that many applications hide all files and directories starting with a dot, which happens to also apply to these two.
- ChrisSD 7y agoAh, thanks for the correction.
- malkia 7y agoAlso peculiar, in Windows, is handling of files that have spaces at the end :) - I've seen in my gamedev career more than one case, where a tool doesn't do enough trimming on spaces only to bite us later.
- Someone 7y agoThere are two distinct sets of restrictions on file names: those of the OS API (in United, that means no null bytes, / is a directory separator), and those of the file systems in the path, which can be (almost) anything. Quite a few file systems require names to be valid text in a specific encoding, not arbitrary byte sequences. Also, note the use of a plural in “the file systems in the path”. A file systems mounted in another one can change the rules halfway-through. There is not single fixed set of restrictions to file names.
- DonHopkins 7y agoGatorBoxes (an AppleTalk<=>Ethernet Apple File Sharing / NFS bridge) would let Mac users create files in the Unix file system with slashes in their names (presumably because of NFS shenanigans going on in the kernel). Macs let you use "/" in file names, but instead used ":" as the path separation character. It seemed to work fine and dandy at the time, until you ran "restore" and discovered your backups were corrupted! https://en.wikipedia.org/wiki/GatorBox https://en.wikipedia.org/wiki/GatorBox https://news.ycombinator.com/item?id=20007875 https://news.ycombinator.com/item?id=20007875 Just for fun: guess what happens when you create a Mac file name with a slash in it today? It works! Or it seems to work. But behind the scenes, the Finder and Mac user interface libraries actually convert the "/" to a ":", which you can see with "ls". But at least it doesn't corrupt your backups!
- nneonneo 7y agoClassic MacOS used : for the directory separator, so you could freely put / in your filenames. Modern macOS converts / in the UI to : under the hood in order to retain compatibility, while banning : in the UI (the same restriction that classic MacOS had).