[hatari-devel] Inconsistency when renaming file on GEMDOS drive

Eero Tamminen eerot at users.berlios.de
Sun Jan 10 12:38:19 CET 2010


Hi,

On Saturday 09 January 2010, Uwe Seimet wrote:
> When renaming a write-protected (by GEMDOS) file on a GEMDOS drive I get
> a strange effect. The filename is HDDRIVER.PRG. When trying to rename it
> to HDDRIVER.PR nothing happens except for this error message:
>
> GEMDOS missing read/write permission to file
> '/home/us/TT.hatari/C/AUTO/HDDRIVER.PRG'

It doesn't work with write access either, I get this when trying to rename
file while having gemdos tracing on:
------
GEMDOS Frename("C:\HDDRIVER.PRG", "C:\HDDRIVER.PR")
conv C:\HDDRIVER.PR -> /home/eero/down/st/test/HDDRIVER.PRG
conv C:\HDDRIVER.PRG -> /home/eero/down/st/test/HDDRIVER.PRG
-------


> But when renaming HDDRIVER.PRG to HDDRIVER.PRX renaming the file works,
> even though I get the same error message.
>
> Something seems to be inconsistent here, as if the outcome of renaming a
> file depends on the length of the filename/extension.

I found the bug in GEMDOS glob() match rules.  It matches shorter GEMDOS
names to longer host names unconditionally.

The long host name handling improvement patch I've been working on fixes
this also, by trying first finding an exact match for the filename and only
then if that fails, checking whether there's a longer variant available *if*
the filename was such that it could have come from a truncated host file or
dir name (of which the code will pick the first one).

It uses readdir() and fsfirst_match() instead of glob().  One of the reasons
for this is that e.g. [] are valid file name characters on GEMDOS, but have
special meaning for glob.

The version of the patch I sent earlier was slightly buggy, the attached one
should work better.  Could you give it a try?


Because the new code now converts also invalid GEMDOS characters in
the host filenames to valid ones, you may still get matches when you
shouldn't, but as that can happen only for names with '@' in them (I convert
all invalid chars to '@'), I don't see this very likely.


NOTE: I found also a bug in the fsfirst_match(), it didn't correctly match
zero characters at the end of a string with "*"[1].  I've commited a fix to
that to repo, please update the Hatari sources before trying the patch
(this fix is more important for my new long name matching code than for
fsfirst that was earlier its only user).


	- Eero

[1] E.g. "HDDRIVER.PR*" pattern didn't match "HDDRIVER.PR"...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gemdos-long-filenames.diff
Type: text/x-diff
Size: 16293 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100110/b2962bb6/attachment.diff>


More information about the hatari-devel mailing list