Mail Archives: djgpp-workers/2001/01/15/15:56:46
> From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
> Sent: Saturday, January 13, 2001 10:55 AM
> Thanks for working on this.
You're welcome.
> 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.
line 167
> 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.
See below.
> 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.
New does exist.
> 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?
Wrong. They are on the same device. TMPDIR=e:/djgpp/tmp,
file=readme.txt, current dir=e:/temp. If they are NOT on the same device
patch DOES work. Wait, I'll double-check that one as well...
> (What are `new' and `old' at this point, btw?)
old="e:/djgpp/tmp/9$$djren$$.$$temp$$", new="readme.txt"
> What is this 183 thingy, anyway? RBIL says:
> B7h (183) (DOS 5.0+,NetWare4) shared segment already exists
> Huh? What ``shared segment''? Weird...
That's exactly what I thought, but I just tell you what 'print r.x.ax'
tells me...
> 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.
That's the right way indeed.
> 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).
This file does get created, see the tracebacks.
> Could you please ifdef out the call to _creat above and see if that
> helps?
Haven't done this, will try tomorrow.
> I think that, together with the other info I requested, this will
> allow us to guess what's going wrong there.
On entry of _rename the backtrace is:
#0 _rename (old=0xb5bb8 "e:/djgpp/tmp/poaaaaaa", new=0xb6118 "readme.txt")
at _rename.c:23
#1 0x11d64 in rename (old=0xb5bb8 "e:/djgpp/tmp/poaaaaaa",
new=0xb6118 "readme.txt") at rename.c:388
#2 0xe7e0 in move_file (from=0xb5bb8 "e:/djgpp/tmp/poaaaaaa",
from_needs_removal=0x33068, to=0xb6118 "readme.txt", mode=420, backup=0)
at util.c:167
#3 0x5a06 in main (argc=3, argv=0xb5ba0) at patch.c:388
#4 0x133a4 in __crt1_startup ()
right before the actual rename the backtrace is (9$$... does exist):
#0 _rename (old=0xb4c24 "e:/djgpp/tmp/9$$djren$$.$$temp$$",
new=0xb6118 "readme.txt") at _rename.c:118
#1 0x11d64 in rename (old=0xb5bb8 "e:/djgpp/tmp/poaaaaaa",
new=0xb6118 "readme.txt") at rename.c:388
#2 0xe7e0 in move_file (from=0xb5bb8 "e:/djgpp/tmp/poaaaaaa",
from_needs_removal=0x33068, to=0xb6118 "readme.txt", mode=420, backup=0)
at util.c:167
#3 0x5a06 in main (argc=3, argv=0xb5ba0) at patch.c:388
#4 0x133a4 in __crt1_startup () */
I tried jumping to the Win98 2143FF BP5053 function, but that gave
r.x.ax=1, r.x.flags = 3. (function not supported).
I think I'll try using the NTLFN package as well, maybe it matters.
Greetings,
Robert
- Raw text -