[hatari-devel] Inconsistency when renaming file on GEMDOS drive
Eero Tamminen
eerot at users.berlios.de
Tue Jan 12 00:17:29 CET 2010
Hi,
While testing this a bit more, I found a couple of issues from my code
(in handling "../" in GEMDOS paths) which are fixed in the attached patch
along with fixes to too small host file name buffers in original gemdos.c
code (those didn't cause crashes, the GEMDOS emulation wouldn't just
work properly if resulting host paths would be over 256 chars long).
- Eero
On Sunday 10 January 2010, Eero Tamminen wrote:
> 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-filenames2.diff
Type: text/x-diff
Size: 17093 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20100112/add5da57/attachment.diff>
More information about the hatari-devel
mailing list