Discussion:
[Freedos-devel] [Freedos-user] after find, Error reading from drive A: DOS area: general failure: fixed
Tom Ehlert
2017-01-19 11:55:54 UTC
Permalink
find bug solved and fixed; contacting the maintainer

TC 2.01 has memory layout

ff95
ff
lfnSupported

now when no LFN are detected,

LFNFirstFile()
findfirst(wildcard, &ff, 0);
findfile(ff, FIND_FIRST, name, attr);
convDOS(ff)


{
memcpy(ff->ff_95.ff_shortname, ff->ff_name, sizeof(ff->ff_name));
memcpy(ff->ff_95.ff_longname, ff->ff_name, sizeof(ff->ff_name));
ff->ff_95.ff_attr95 = ff->ff_attr;

the last statement accesses memory behind ff, because ff is
ffblk ff;

and not ffblk95 ff;

the following source code fixes the bug

**** LFNAPI.C ***************************************************************************************************************


#include <dir.h>
#include <string.h>
#include <dos.h>

#include "io95\io95.h"
#include "io95\find95.h"
#include "lfnapi.h"

/* MAP files are useful !! */
#define STATIC


STATIC int CheckDriveOnLFN(char drive)
{
struct REGPACK rp; /* temporary stack for the registers */
static char strDrive[4];
static char filesys[32];

strcpy(strDrive, "?:\\");
strDrive[0] = drive;

rp.r_flags = 1; /* asure that the carry is set */

rp.r_ax = 0x71A0;

rp.r_ds = FP_SEG(strDrive);
rp.r_dx = FP_OFF(strDrive);

rp.r_es = FP_SEG(filesys);
rp.r_di = FP_OFF(filesys);

rp.r_cx = 32;

intr(0x21, &rp);

if (rp.r_flags & 1)
return 0;

return (rp.r_bx & 16384) > 0;
}

STATIC int
IsLFNSupported (char *filename)
{
if (filename && filename[0] && (filename[1] == ':'))
return CheckDriveOnLFN (filename[0]);
else
return CheckDriveOnLFN (getdisk () + 'A');
}

int LFNConvertToSFN(char* file)
{
static char buffer[67];

if (IsLFNSupported(file))
{
if (lfn2sfn95(file, buffer) == 0)
{
strcpy(file, buffer);
return 1;
}
else
return 0;
}

return 1;
}

STATIC int lfnSupported;
STATIC union {
struct ffblk95 ff95;
struct ffblk ff;
} finddata;

int LFNFirstFile(char* wildcard, char* file, char* longfile)
{
int retVal;

if (IsLFNSupported(wildcard))
{
lfnSupported = 1;

retVal = findfirst95(wildcard, &finddata.ff95, 0);

if (retVal == 0)
{
strcpy(file, finddata.ff95.ff_95.ff_shortname);
strcpy(longfile, finddata.ff95.ff_95.ff_longname);
}

return retVal;
}
else
{
lfnSupported = 0;

retVal = findfirst(wildcard, &finddata.ff, 0);

if (retVal == 0)
{
strcpy(file, finddata.ff.ff_name);
strcpy(longfile, finddata.ff.ff_name);
}

return retVal;
}
}

int LFNNextFile(char* file, char* longfile)
{
int retVal;

if (lfnSupported)
{
retVal = findnext95(&finddata.ff95);

if (retVal == 0)
{
strcpy(file, finddata.ff95.ff_95.ff_shortname);
strcpy(longfile, finddata.ff95.ff_95.ff_longname);
}

return retVal;
}
else
{
retVal = findnext(&finddata.ff);

if (retVal == 0)
{
strcpy(file, finddata.ff.ff_name);
strcpy(longfile, finddata.ff.ff_name);
}

return retVal;
}
}

void LFNFindStop()
{
if (lfnSupported)
{
findstop95(&finddata.ff95);
}
}

***********************************************************************

Tom
Jerome Shidel
2017-01-21 22:56:05 UTC
Permalink
Hello Tom,

Did you get hold of the maintainer?

The package lists that as Eric Auer. But, that could be incorrect.

I just haven’t heard anything for a couple days and was wondering what was going on with find.

Jerome
Eric Auer
2017-01-22 01:21:45 UTC
Permalink
Hi Tom and Jerome,

it is correct that I have once compiled a version of FIND,
but I have yet not found time to find out what *changes*
the updated code snippet by Tom provides. Because I would
be interested to understand what originally was wrong :-)

Of course, if somebody else wants to compile FIND with the
updated code, it would be just as good. As mentioned earlier,
compilation with Turbo C (NOT Turbo C++ and not OpenWatcom C)
has the advantage of creating a SMALL binary for FIND, which
is good when you want to put it on a classic tool floppy disk.

Maybe Tom could mail a diff -u to illustrate his patch here?

Thanks! Cheers, Eric
Post by Jerome Shidel
Hello Tom,
Did you get hold of the maintainer?
The package lists that as Eric Auer. But, that could be incorrect.
I just haven’t heard anything for a couple days and was
wondering what was going on with find.
Jerome
Tom Ehlert
2017-01-22 16:56:33 UTC
Permalink
Hi Eric,
Post by Eric Auer
it is correct that I have once compiled a version of FIND,
but I have yet not found time to find out what *changes*
the updated code snippet by Tom provides. Because I would
be interested to understand what originally was wrong :-)
was detailed in the mail :-<
Post by Eric Auer
Of course, if somebody else wants to compile FIND with the
updated code, it would be just as good.
it's not (I can easily do that)

but this should be compiled. put into a package, go to ibiblio, ...
i.e. maintainer stuff
Post by Eric Auer
As mentioned earlier,
compilation with Turbo C (NOT Turbo C++ and not OpenWatcom C)
has the advantage of creating a SMALL binary for FIND, which
is good when you want to put it on a classic tool floppy disk.
Maybe Tom could mail a diff -u to illustrate his patch here?
I NEVER do things that you can do exactly as easy as I.
the full source was in the mail.

In fact you can do it even easier as I have no diff around.

Tom

Loading...