www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/05/03/22:41:47

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Message-ID: <001901c1f315$16566cb0$0102a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: "Charles Sandmann" <sandmann AT clio DOT rice DOT edu>
Cc: <djgpp-workers AT delorie DOT com>
References: <10205010348 DOT AA12477 AT clio DOT rice DOT edu>
Subject: Re: _open LFN & Win 2K Bug (Was Re: a bug)
Date: Sat, 4 May 2002 12:39:36 +1000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Reply-To: djgpp-workers AT delorie DOT com

> > I get the same result when I add printing the _doserrno. Charles do you
want
> > to mod  the doserr_to_errno translation table and send me a copy so I
can
> > double check it or do you want me to do it and send it to you to double
> > check? Better save than sorry as there are 255 entries to check against
RB's
> > interrupt list table 1680.
>

I thought about modifying doserr_to_errno and the modifiaction may not be
the best place to put the change as the modifiaction to the table will then
propogate to all dos errors to errno conversions. This may be okay and
correct, but if it is not then the following potential modification may be
more approporiate as it only affects LFN W2K/XP code and does not change any
other files appart from the low level _open() function. The following is a
potential modification to the exisiting _open() function.

What do you think? I need to test this some more, but so far the followign
tests appear to be okay:-
    - sfn file exists                    (test.exe)
    - lfn file exists                    (longfilename.txt)
    - lfn file does not exists       (longfilename.dog)
    - file does not exist with no wildcards    (unknown.txt)
    - file does not exist with wildcards        (*unknown.txt)
    - device                                     (\dev, \null)

  if(use_lfn && _os_trueversion == 0x532)
  {
.....
SNIP
.....

 /* Fail on short name open after _chmod said OK.
    Device with directory?  We should re-try with LFN.
    Permission?  Readonly file?  We should quit.
    Let it fall through to the LFN open which should succeed.  */
      }
      else
      {
            /* Modifiaction for the case where trying to open the file in
SFN fails and therefore LFN will also fail, if the file does not exist then
on W2K and XP
                the int21 716C function returns a wrong value and causes
problems with the __doserr_to_errno() function. This hopefully fixes it.
            */
            r.x.ax = 0x6c00;
            r.x.bx = (oflag & 0xff) | 0x1000; /* 0x1000 is FAT32 extended
size. */
                  /* FAT32 extended size flag doesn't help on WINDOZE 4.1
(98). It
            seems it has a bug which only lets you create these big files
                 if LFN is enabled. */
            r.x.dx = 1;                        /* Open existing file */
            r.x.si = __tb_offset;
            r.x.ds = __tb_segment;
            _put_path(filename);
            r.x.cx = 0;
            __dpmi_int(0x21, &r);
            if(r.x.flags & 1)
            {
                errno = __doserr_to_errno(r.x.ax);
                return -1;
            }
      }
    }
  }

  if(use_lfn)
  {


I spotted one other potential problem when testing this solution and found
the following:-
    In open() after calling _opne() there is a call to
__file_exists(real_name) which sometimes changes the _doserrno. This causes
differences between LFN=y and LFN=y results when printing _doserrno, errno
does not get changed. Is this a bug or a quirk?



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019