Re: [hatari-devel] GEMDOS filename handling

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 31 heinäkuu 2014, Eero Tamminen wrote:
> On torstai 31 heinäkuu 2014, Eero Tamminen wrote:
> > On torstai 31 heinäkuu 2014, Max Böhm wrote:
> > > I found something else which may need attention: When you create a
> > > file "atari.log" through the GEMDOC HD layer on the host and then
> > > copy another file "atari.lo" into the same directory, the two files
> > > seem to be mapped to the same host file by the GEMDOS layer. The
> > > emulated system reports that "atari.lo" already exists although this
> > > should not be the case.
....
> Max, this was due to faulty logic for matching host names which
> might be so long that they get clipped to 8+3 characters.  In
> worst case matching pattern is:
>    filename*.ext*
> 
> Such a pattern is used if part before extension is 8 chars, extension
> is 3 chars and there was no match without a pattern.  Otherwise
> host filenames clipped to 8+3 couldn't be matched from the clipped
> Atari name back to host.  It's possible that it matches multiple
> filenames, but that's expected as you will see also on Atari
> side multiple filenames (with the same 8+3 name representation).

Max, because your patch does also atari->host conversions which
can return multibyte character strings, you need also to patch
the longer than 8+3 filename handling to take into account
multibyte strings.

Current code for that assumes that file names passed from Atari side
are all ASCII (>127 chars replaced with INVALID_CHAR) and doesn't
handle '.' separators in multibyte character strings correctly.

Test cases that you need for that are _host file names_ that are
longer than 8+3 and contain e.g. accented letters.  Testing for
that needs to be done on a host system which uses multibyte
file name strings.

Best is to have exactly 8+3 long names and ones where base  extension
parts are one letter shorter & longer than that and see how well they
get matched, in addition to really long base & extension names.

Attached is my old tester for this.  You'll need also to generate
matching file names to GEMDOS HD directory.

I think both add_path_component() and clip_to_83() in gemdos.c
need changes for multibyte file name string handling.


	- Eero

Ps. I won't be answering mails for a while.

/*
 * Tester for how too long file names, both in the base and in the
 * extension part are handled by TOS and Hatari GEMDOS HD emulation.
 */
#include <stdio.h>

void try_open(const char *fname)
{
	FILE *fp;
	if ((fp = fopen(fname, "r"))) {
		printf("Opening '%s' = %d, SUCCESS\n",
		      fname, fileno(fp));
		fclose(fp);
	} else {
		printf("Opening '%s', FAIL\n", fname);
	}	
}

int main()
{
	try_open("1234.123");
	try_open("12345.123");
	try_open("1234.1234");
	try_open("12345678.123");
	try_open("123456789.123");
	try_open("12345678.1234");
	try_open("123456789.1234");
	try_open("1234.DIR\\TEST");
	try_open("12345.DIR\\TEST");
	try_open("1234.DIRS\\TEST");
	try_open("12345678\\TEST");
	try_open("123456789\\TEST");
	try_open("12345678.DIR\\TEST");
	try_open("123456789.DIR\\TEST");
	try_open("12345678.DIRS\\TEST");
	try_open("123456789.DIRS\\TEST");
	fgetc(stdin);
	return 0;
}