Minuous wrote:colinw wrote:Just because the shell has "special" uses for some characters, and the pattern matcher
also does too, and a couple have special meaning for DOS, ( namely colon and slash ), doesn't make them "illegal" in a name
Colon and slash are illegal in filenames; this is stated in the official AmigaDOS Manual (section 1.1).
I'm sure it probably says that, I don't have a copy on hand, but...
Here is the situation, whether a particular character is going to cause trouble is completely dependant upon
the interface or subsystem you are going to access it through, for example;
It would be extremely unwise to use characters reserved for pattern matching control if you were accessing it
through something that uses the pattern matching functions, like the C: commands for instance.
It would be extremely unwise to use characters reserved for shell control like spaces and >< etc...
if you intended to access it through a commandline, as these are used as word delimiters and stream control.
As far as DOS is concerned, it uses only two characters, colon and slash to parse a DOS path out of a string,
(and it only uses the first colon it finds by the way), so if you were to pass something that had those,
through a DOS function like Open() or Lock(), which is required to split up the path components,
to find which file handler and directory should be used, then all kinds of problems will likely visit you.
Ultimately, the filesystem is responsible to decide what characters are allowed, but the problem is that unless
those characters are in the low 7 bit ascii range, (<0x7F) the filesystem cannot decide because it is completely
unaware of the current charset map or locale settings or even if you are passing it a UTF-8 encoded name.
It just stores what you give it. If it even tried to get too-smart, it would undoubtedly break something.
However, after saying that, and that it should be obvious that a user shouldn't do it, it probably would be
acceptable for a filesystem to limit creating names with a ":" or "/" just incase.