Re: [hatari-devel] GEMDOS filename handling

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Sorry for the late reply, I was traveling, and then sick.

On lauantai 02 elokuu 2014, Max Böhm wrote:
> 2014-07-31 15:06 GMT+02:00 Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > After improving the test (attached), and testing it with
> > TOS 2.x (results attached), I found out that even native
> > TOS has problems with files & directories having following
> > characters in them: ' ', '*', '.', '?', '\'.

I've now tested almost all TOS versions:
- Except for TOS v4, all real TOS versions behaved like stated
  above.  TOS v4 additionally accepts ' ' in file names.
- EmuTOS rejects many additional characters: ,:;<=>[]|
- TOS v1.02 is too unstable with this amount of disk content,
  even with folder300.prg.


Btw. TOS v4 crashes with Dcreate("\TEST"). A bit surprising,
as all other TOS versions worked fine with the same binary,
But maybe it's some AHCC TOS v4 incompatibility, not TOS bug...


> Can it be that the host system does not allow these characters?

This was testing with plain TOS, on an emulated floppy image.
There was no GEMDOS HD emulation or host files involved.

Are you sure your earlier TOS testing worked properly
(your test program referred drive L: in the paths, maybe
that was mapped to GEMDOS drive in your hatari.cfg)?


It's interesting that the TOS error for trying to create files
with invalid chars in them was -36, EACCDN (Access denied).
For TOS v4, error is -5, EBADRQ (Bad request).

-> It seems that TOS actually validates/rejects paths.
   Hatari GEMDOS HD emulation should do the same.


For '\' & '.' the error is -34, path not found, same as when trying
to delete already created folders with '*' or '?' in their name.

-> I think '\' & '.' don't need to be specifically filtered out,
   they get rejected by last '.' clipping and path not matching.

-> This leaves '*' and '?' as something that needs to be checked
   and paths with them rejected at GEMDOS call level. In case of
   TOS <v4, also paths with ' ' in them need to be rejected.


> On my system (Ubuntu 14.04 VM) files with those characters
> can be created and removed by the emulated system, see attached
> logs (linux.zip). Only '\' and '/' do not work.

It's a TOS limitation, not a host one.

It doesn't make sense to offer/accept to emulation programs
paths that wouldn't work with real TOS.


> >> The other alternatives are:
> >> - instead of '?', using glob() pattern with '[]', which contains all
> >> 
> >>   the invalid characters (after your 8-bit char patch, amount of
> >>   invalid chars is small enough to be handled like that).
> >> 
> >> - or first trying with INVALID_CHAR and if that doesn't match, try
> >> 
> >>   with pattern
> 
> Not sure if this would work, as for Windows with cp1252 encoding there
> are more invalid characters (all the greek characters 0xC0..0xDC, and
> some others)

In which way these characters are invalid?

Earlier you stated that only these characters are problematic:
   "Characters on Windows:    " * / : < > ? \ |"

(which list resembles one used by EmuTOS.)


	- Eero

Attachment: filename-tos4.log.gz
Description: GNU Zip compressed data

Attachment: filename-tos3.log.gz
Description: GNU Zip compressed data

Attachment: filename-etos.log.gz
Description: GNU Zip compressed data