This is incorrect. For example "&" is not allowed in directory names.

Are there any others ?

Hi there,

says who? Okay, maybe there is some spec somewhere claiming this, but in practise, the '&' character works just fine in file and directory names. I'm using that quite frequently on ext2,3,4 file systems, and also on alien FAT and NTFS file systems. Never had a problem about this, and no fsck ever complained about this. But there may be other file systems that do make trouble with '&'.

However, there are some characters you'd better avoid (though it's possible to use them) as they may cause trouble in certrain scenarios, for example '%', '+', ':', '<', '>', '|'. Also I read occasionally that braces and square brackets are troublesome here and there, though they can be used if they are properly escaped on the command line.

I should think that the shell wildcard characters '*' and '?' are also strictly forbidden.

[X] Doc CPU

1 members found this post helpful.

& does not work in Puppy 5.9.

It may work in other distros.

Which file system are you using? How are you trying to create the folder? I just created and deleted a directory with an ampersand in the name under Debian Sid on and ext4 partition no problem I also created a directory with the name & and that was fine too though, of course, I had to use quotes to create both with mkdir.

1 members found this post helpful.

The set of disallowed characters is a limitation of the file system in question, not the distribution.

Applications and (especially) scripts may not escape and/or quote characters properly, and may therefore have trouble handling file names containing characters that must be escaped/quoted when used in a shell. Try this in a terminal window:

I wasn't using the quotes when making the directory.

:-)

That would certainly explain it . If you don't then, as you have seen, the symbol is interpreted by the shell instead of as part of the file name.
All the above said personally I tend to avoid creating directories and files with any characters which could cause this kind of problem, including ampersands and spaces. I do have some directories with spaces and ampersands in the names but only because I'm too lazy to change them in all the locations they are stored.

Where possible try and avoid ANY characters that need escaped, and also while spaces ARE allowed try and use _ instead. I've recently had to deal with file transfers using rsync & scp where applications designers decided to use Windows reserved characters as well as spaces, and even "::" in file names, this caused no end of problems when trying to escape things for use with SCP.


For anyone that's interested I ended up using this to "clean up" file names in a folder.


For anyone that's interested here's a link to what Windows considers invalid characters: http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

All characters except "/" are valid in native UNIX file system file and directory names and hence in native Linux file systems.

It is impossible (?) to create a file or directory with an ASCII NUL (value 0) in the name.

It is a matter of choice whether to avoid characters that are meaningful to the shell and hence which require care on the command line.

Hi there,

I disagree. While of course everybody should get happy their own way, my position is that file names should map real-world names as closely as possible. That's why I do encourage the use of spaces, ampersands, umlauts or punctuation marks where they're appropriate. However, I know there are some technical restrictions, partly by the file system, but more so by the software being involved, and I reluctantly accept them if there's no way of circumventing them. Escaping those offending characters is such a way of circumventing restrictions, and a compliant one at that.

I avoid the underline wherever possible - simply because I find it ugly.

Hehe. Broken software ...
But seriously, some time ago I was totally at a loss: I tried to copy a file from a Linux box to a Windows box via Samba and Windows file sharing. This had worked well for a long time. But the Linux machine (Thunar, for that matter) kept telling me that the file couldn't be copied because of unsufficient access rights on the target computer. It took me quite some time (and a lot of double-checking of permissions and Samba settings) until I noticed that the file name had a colon ':' in it, which is forbidden in Windows. ;-)

It is. And the very first reason is that the NUL character would be considered the end-of-string marker, so it cannot be part of a NUL-terminated string.

[X] Doc CPU

I don't recall the details but I thinlk the reason the colon is not allowed is because it refers to a different stream which, if I recally correctly, was a function of NTFS which was never implemented fully.

Hi there,

it's much more obvious and dates back to the stone age of DOS, where the colon was used to separate a device name (most frequently a drive letter) from the actual path or parameters. Windows has just dragged along that legacy ever since.

[X] Doc CPU

Are you sure? NTFS now allows characters which weren't possible with older file systems -- I think some accented characters may be allowed also from a vague recollection of dealing with German and Spanish file and "directory" names.
I did get the impression that either file streams were scrapped by MS due to time and cost restrictions or were only there due to NTFS being based upon previous work though the latter is probably me confusing it with Active Directory and LDAP.
Edit: oops, forgot the link:
http://support.microsoft.com/KB/105763

Hi there,

yes, that's true. But don't confuse things. Characters with codes >0x80 were allowed as part of "long file names" introduced in Windows 95. You may or may not remember that the consumer branch of Windows 4 (that is, 95, 98, and its downgrade ME) were two-pronged: Each file had a backward-compatible 8.3 file name with all the restrictions that ever existed (only uppercase letters, digits, and a very small set of punctuation characters), and optionally it had a long file name, which was very liberal right from the start.

There were a lot of problems about this; some programs saw a directory "Program Files", others saw "PROGRA~1", which was factually the same. Some even used the truncated short names and seemed to hope that they were linked to their long counterparts by some kind of magic. Well, it was a mess.

For quite some time, NTFS mimicked that behavior, and I think it's only since Windows 7 that MS dropped the legacy 8.3 file name scheme entirely.

I don't know anything about these alternate streams other than they exist in NTFS. I've never seen an application actually using them, never seen a convincing theory or explanantion what they're good for.

[X] Doc CPU

While anything can be stored in an NTFS Alternate Data Stream, they are most commonly used for storing metadata. For instance, when a file is downloaded from the Internet and saved on an NTFS volume, Windows will store information about the file's origin ("zone") in an ADS called "Zone.Identifier". In that sense, Alternate Data Streams can be considered the NTFS version of Extended Attributes (although NTFS supports POSIX Extended Attributes as well).

Being able to store and modify metadata without having to touch the actual contents of a file is very convenient, but unfortunately no standard for ADS metadata storage exists on the Windows platform, so except for the (very) few instances where the OS itself creates and maintains such streams, this doesn't really work across applications.

Also, The fact that this feature it tied to one specific file system probably hasn't helped in its adoption. Even ReFS didn't initially support ADS.