Message-ID: <000501c07f34$cfdd7d00$1b354bd5@robert> From: "Robert van der Boon" To: "Eli Zaretskii" Cc: References: <000501c07c0e$9c67ab40$d7394bd5 AT robert> <7704-Sat13Jan2001115518+0200-eliz AT is DOT elta DOT co DOT il> Subject: Re: patch.exe (fwd) Date: Mon, 15 Jan 2001 21:44:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id PAA03584 Reply-To: djgpp-workers AT delorie DOT com > From: "Eli Zaretskii" > 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