Special Characters and Pattern Matching

[Amigo1]

Hi all,

let's say I was particularly smart and executed the following command:

Code: Select all

copy clone s:user-startup "ram:User-Startup_`date "

how can I delete this incredible brain flower?

I tried with pattern

Code: Select all

 delete "ram:user#?"

or

Code: Select all

delete ram:user#?

I tried a single pattern matching char

Code: Select all

 delete "ram:user-startup_2019-12-02 08?58" 

and using apostrophe to escape the column

Code: Select all

 delete "ram:user-startup_2019-12-02 08':58" 

Code: Select all

 delete "ram:user-startup_2019-12-02 08'':58" 

each time I got a system requester asking me to "Please insert volume user-startup_2019-12-02 08: in any drive."

The file does not even appear in a Workbench window, I can list the file in a shell, but the RAM: Window in Workbench is empty, except for T and clipboards. Also when I double-click on the RAM Disk Icon, workbench asks for the same Volume. Every now and then, I get a DSI too.

Is my only option to cold reboot the System? A warm reboot makes it hang at the AmigaOS 4.1 FE splash screen after I tried the above..

[nbache]

DOpus4 can delete it - just tried it here.

Best regards,

Niels

[Amigo1]

DOpus4 can delete it - just tried it here.

Best regards,

Niels

As helpful as always! Thank you!

Do you think it is a bug or is it how it is supposed to work on the shell and workbench part but it's worth to ask for an enhancement?

[thomasrapp]

I would post a bug report. RAM-Handler should not accept colons in file names when creating new files.

[colinw]

I would post a bug report. RAM-Handler should not accept colons in file names when creating new files.

No, you are completely allowed to shoot yourself in the foot anytime, "AmigaOS" is not "NannyOS".
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,
it just makes them incredibly inadvisable to use in a name, with an extra splashing of damn stupid,
if you want to access the name from a commandline or using pattern matching.
Hey, even putting a space in a name will make peoples head explode when trying to access it from a shell.

If the shell, DOS or filesystems started filtering "acceptable" names, i'd never hear the end of it.
Then there is the problem of who decides what is "acceptable".

You may want to create a directory called "b4ip:keep:out:of:here", that will do exactly what you want.
As it is now, the newer filesystems and DOS can also use UTF-8 encoding, i'm sure there will be some
interesting name combinations with that too.

[nbache]

It's a part of the total picture, though, that trying to do the same as the OP showed, on NGFS, SFS or FFS results in an error message. Not necessarily a useful and informative one, but at least one that prevents the file from being created.

On FFS and NGFS it says that the object couldn't be opened for writing because it doesn't exist, on SFS (1.290) it says that the object name is invalid.

Edit: This is with the Danish country settings, in which the date format contains a slash (/). If I repeat the test, using the generated name explicitly, except with the slash replaced by a dash, both FFS and SFS say that the object name is invalid, whereas NGFS actually allows me to create the file.

E.g.:

Code: Select all

copy clone s:user-startup "NGTest:User-Startup_Tirsdag 03-12-2019 10:24:58"

Best regards,

Niels

[MichaelMerkel]

isn't there an escape character which can be used in this case with the dos commands?
like the backslash in linux?
i mean, that's what an escape character good for...

regards...
michael

[thomasrapp]

The escape character can be used to escape wildcard characters from pattern matching.

In this thread the issue is different. The file name containing a colon does not take part in pattern matching, it is presented to the handler and the handler can decide whether it is a valid file name or not.

In case of impossible file names the handler should refuse them.

BTW, this works correctly in OS3. It is a bug which was introduced in OS4. So it should be fixed.

[Minuous]

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).

[colinw]

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.