Date:	Sat, 13 Jan 2001 11:55:19 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	rjvdboon AT europe DOT com
Message-Id:	<7704-Sat13Jan2001115518+0200-eliz@is.elta.co.il>
X-Mailer:	Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6
CC:	djgpp-workers AT delorie DOT com
In-reply-to:	<000501c07c0e$9c67ab40$d7394bd5@robert> (rjvdboon@europe.com)
Subject:	Re: patch.exe (fwd)
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1010109095357 DOT 19017B-100000 AT is> <000501c07c0e$9c67ab40$d7394bd5 AT robert>
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> From: "Robert van der Boon" <rjvdboon AT europe DOT com>
> Date: Thu, 11 Jan 2001 21:37:06 +0100

Thanks for working on this.

> > Once you have a debuggable binary that reproduces the problem, please
> > run it under a debugger and see what happens where `rename' is called.
> 
> Fails (returns with -1, errno = ENOMEM)

Please tell me where exactly in the Patch sources does this happen.  I
think it is either line 167 or line 178 of util.c, but please say
which one.

Also, a backtrace inside a debugger, when you are in _rename, would be
useful to understand where exactly in Patch's execution thread does
the problem happen.

> Only change with latest CVS was symlink support, which means
> downloading more than just the 2 files. Didn't do that, sorry.

That's okay, it shouldn't matter.

>     _put_path2(new, olen);
>     _put_path(old);
>     __dpmi_int(0x21, &r);
>     if(r.x.flags & 1)          <<-- r.x.flags = 3, so is true
>     {
>       if (i == 0            <<-- r.x.ax = 183
>           && (r.x.ax == 5 || (r.x.ax == 2 && __file_exists(old))))
>         remove(new);   /* and try again */
>       else
>       {
>         errno = __doserr_to_errno(r.x.ax);    <<-- r.x.ax = 183 (ENOMEM)

Okay, this is our villain: the __dpmi_int call either shouldn't have
failed (if `new' didn't exist) or was supposed to fail with 5 in EAX.
Actually, in this case, I'm guessing that it should have failed with
17 in EAX (not same device), since the two files are not on the same
drive, right?  (What are `new' and `old' at this point, btw?)

What is this 183 thingy, anyway?  RBIL says:

   B7h (183) (DOS 5.0+,NetWare4) shared segment already exists

Huh?  What ``shared segment''?  Weird...

Well, since this function only fails when LFN is enabled, I think we
need to find out what part(s) of _rename which only work under LFN
cause the failure.  Two things that come to mind are: the snippet
which creates the file with the old name:

    /* Now create a file with the original name.  This will
       ensure that NEW will always have a 8+3 alias
       different from that of OLD.  (Seems to be required
       when NameNumericTail in the Registry is set to 0.)  */
    lfn_fd = _creat(old, 0);

and the snippet which renames the old file to a weird name
"X$$djren$$.$$temp$$" (where the initial X is replaced by some
character).

Could you please ifdef out the call to _creat above and see if that
helps?

I think that, together with the other info I requested, this will
allow us to guess what's going wrong there.

> For completeness I must add that _osmajor = 5, _osminor = 0 on
> W2K Professional SP1.

Thanks; this is expected: NT and W2K both return 5.0.

> I don't have much experience with this kind of programming

Please ask any questions you cannot figure out by looking at the code
and the comments.  I think it's important to understand what the code
tries to do in order to debug this efficiently.

Thanks again for your time and efforts.

- Raw text -