> AFAIK, everything else is fair game, even emojis
FWIW, I generally expect emojis to be more compatible than other symbols, because they have no legacy meanings - ex. ™ has never been a path separator, or indeed anything else.
Main problem with "emojis" is that they live outside the basic multilingual plane, and so make bad utf-16 handling really obvious. This is a blessing in disguise, because it acts as a no-brown-m&ms thing, since it's more unarguably broken than not being able to use cuneiform, or musical symbols.
Yeah, point; I probably should have said something more like "emoji shouldn't have alternative meanings, so they should work if your unicode support is functional (which is a big caveat)." On the bright side, yeah, emoji have been great at pushing things to handle unicode nicely and act as a... I dunno, natural fuzzing case?
Oops, good point. I think I'm going to leave it as-is on account of not knowing of any actual emoji that HN allows, but yes that is technically incorrect on my part.
And it was merely not recommended to use a fullstop at the start of a filename. Device drivers —perhaps just for storage devices — were usually named this way (and also marked invisible). There was an alleged chance the OS would try to load your non-driver file as a driver for the device it resided on. Though I was unable to make it happen.
NTFS itself has not that many forbidden characters (though ':' is one of them, it denotes alternate stream).
What people think about those CON, PRN, AUX, NUL etc are not filesystem limitation.
And while we are here - nor backslash, nor forward slash are used in NTFS. It can care less about what char do you use for a directory separator. Just be sure to update your APIs.
NTFS on non-Windows systems aside, I wonder whether there are any "pure NT" environments you can access in Windows where you can create and use these folders.
You just need to come in below whatever layer notices them. I'm sure they've been used to smuggle viruses in, so the layer that blocks them may get lower and lower.
> [...] and only disallows the ascii slash and null. All other bytes are fair game.
There's also the special treatment of "", ".", and ".." (that is, a file or directory name consisting entirely of zero, one, or two dots), and the convention that a name starting with a dot is hidden.
Yes, and it was an absolutely horrible mistake in the other direction. If I give you a path “./something/example.txt” it could be a file called example.txt in a folder called something or it could be a single file called “something/example.txt”.
> : on disk, in classic Mac OS, and at the Carbon layer in macOS; / at the Unix layer in macOS
APFS:
> In the Finder, filenames containing / can be created, but / is stored as a colon (:) in the filesystem, and is shown as such on the command line. Filenames containing : created from the command line are shown with / instead of : in the Finder, so that it is impossible to create a file that the Finder shows as having a : in its filename.
It doesn’t make sense tbh, it just causes confusion when someone is using terminal. Slashes in file names are forbidden everywhere except Mac, it needs to be changed in order to send it anywhere or use in some apps. But I think colon is used much more in names. I don’t get why did they do that.
Once I planned to share files between a Mac and a Win PC through a product synching folders but gave up very soon due to the constant errors and problems with file names worked in one but not in the other, dominantly filenames that I did not choose but received (e.g. link dragged from address bar to folder, but others too) but some I choose following some preexisting logic.
It’s pretty irritating when files and folders on my Mac can’t be uploaded to Teams due to this limitation. It’s only forbidden for Windows users.