If that is your whole question:
Yes, file naming is different between Windows and Unixes. But the differences are minor. Here are the ones I can think of off-hand, with the most important one up front:
- Unix has hard links. This allows the same file to appear at two different paths, for example two different names in the same directory, or in two different directories (which have to be within the same file system). The file exists only once, and gets deleted when its last name vanishes (which implies that an existing hard link always points to an existing file). Both files will have the same attributes: size, permissions, ownerships, and other attributes (EAs, ACLs and all that stuff). The two directories the files are in may have different attributes though.
- Unix has soft links. In a nutshell, this means: when a program tries to use this file, it usually interprets the content of the soft link as a file name (relative or absolute) and uses it instead. That is called "following the link". But programs can explicitly decide to not follow the link, and operate on the link instead. Soft links do not have referential integrity: the link can point to a file that does not even exist. For that reason, one should think of soft links as a way of storing a short string in a file system, and that string can be pretty much arbitrary; by convention it is a file name, and most programs will interpret it that way, but I can instead store a paragraph of the novel I'm writing in there.
- Unix can have files that have no name at all. Those files are by construction temporary, since they get automatically deleted when the program(s) using them right now ends. They can't be found in directory listings (duh).
- Windows has neither hard nor soft links, and I think it uses a different mechanism for temporary files. Instead, Windows has reparse points, which can be used in place of soft links, but are actually much more powerful.
- Most modern Unixes allow relatively long file names, with a typical length of 1024 per component (not the whole path, but each individual name entry along the path). If I remember right, Windows restricts each name to about 200 or 300 characters. In practice, this makes little difference, as few people use file names that insanely long.
- In Unix, the file name is a sequence of bytes, and the character encoding is unspecified. So it is possible to store a valid ISO8859-1 file name, and when reading the file name back (for example with the readdir() call, which is what ls uses) interpret the bytes wrongly as Unicode in UTF-8. The kernel and file system really have no idea what the sequence of bytes means, and how it should be rendered on the screen, or how it should be encoded into a character set. In practice, this makes little difference today, as nearly every process uses UTF-8 encoding, so one can pretty much (but not completely!) rely on file names being UTF-8. In contrast, Windows has always used a 16-bit encoding of the windows character set for file names (at least starting with NTFS). That means that file names can not always be translated between the two: it is possible to have two files names in Unix that would be interpreted as the same file name in Windows if transcoded, and that doesn't work when moving data back and forth.
- On Unix, any byte (character?) is valid in a file name, except for the NUL character (which ends the name string), and the slash character. On Windows, a whole bunch of characters and strings are invalid: You can't use file names such as PRT: or A>B. My personal taste agrees with Windows here.
- Most Windows file systems are case blind or single case. In addition the old FAT file system (the original DOS and Windows file system) was restricted to 8.3 length. Most Unix file systems are case sensitive and can store both cases. Exceptions exist; for example, on a Mac you can configure a traditional Unix file system to be case blind but case preserving, and I think modern Windows file systems such as ReFS can be configured either way.
