[Made obsolete by 1999-05-25 change to never call an external patch program. It isn't clear to me the exact circumstances under which this bug occurs. Doesn't Windows pick short filenames to avoid mapping two different long filenames to the same one? In any event, CVS 1.9.8 (or so) and later apply patches internally rather than via PATCH.EXE, so it is only an issue for compatibility. Someday we might want to define DONT_USE_PATCH on Windows because of this problem, but I don't think I've seen anyone else report it, so I'm unclear on the impact of the problem -kingdon, Jan 1998 Nice catch! The patch you sent is pretty good, but it still could use a cosmetic cleanup or two (PATCH_ORIG_ENDING instead of _WIN32). I may get around to doing so and checking it in, but as usual I might not get to it any time soon. -kingdon, May 1997] From: Shankar Unni Subject: Patches for Win95 cvs problems To: bug-cvs@prep.ai.mit.edu Date: Fri, 21 Mar 1997 16:00:06 -0800 (PST) Attached is a patch (on CVS 1.9.2) for two problems I ran into using CVS on Windows 95 (as a client in a client-server environment). NOTE: I am not on the bug-cvs list, so if you want to reply to me, please add a cc: to me (shankar@chromatic.com) in addition to bug-cvs. 1. If I had done a *readonly* checkout of a file called "Makefile" (any valid 8.3 name seems to have this problem), and later do a "cvs update" on it, I get an error from "patch": it turns out that CVS invokes patch with an explicit "-b ~", and Windows maps "Makefile" and "Makefile~" to the same underlying 8.3 filename. This causes several problems because patch renames Makefile to Makefile~, and promptly tries to clobber it using the newly generated Makefile (which means that if the patch fails for some reason, then the original, possibly modified, file, is lost). Worse, if Makefile was readonly to start with (this is the more serious, immediate problem), then the clobbering of Makefile~ with Makefile fails, and the CVS process gets an error exit from patch and itself errors out. I put in a patch under "#ifdef _WIN32" to pass "-b .orig" instead of "-b ~". Unfortunately, I can't do this as an unconditional change, because there are still 14-filename-character-limit Unixes out there.. . . . Both these are pretty easy to reproduce: for "1.": just check out a file called "Makefile" as read-only (using cvs -r or CVSREAD=1), and then try to update to a newer version. . . . Here is the patch: [hand-edited to separate this out from the other patch which was submitted along with it -kingdon] Fri Mar 21 15:38:30 1997 Shankar Unni * src/client.c: pass ".orig" as the explicit suffix to patch on Win32 instead of "~": FAT maps "Makefile" and "Makefile~" to the same underlying 8.3 filename, causing problems, especially if Makefile was readonly in the first place (e.g. as a result of setenv CVSREAD=1). *************** *** 1564,1570 **** --- 1602,1617 ---- backup = xmalloc (strlen (filename) + 5); strcpy (backup, filename); + #ifdef _WIN32 + /* Win95 uses the same underlying 8.3 name for, say, "Makefile" and + * "Makefile~", which causes much confusion later, especially if + * the file is read-only, so we use at least one alphanumeric + * character in the backup file suffix to force Win95 to pick + * another 8.3 name. */ + strcat (backup, ".orig"); + #else strcat (backup, "~"); + #endif /* _WIN32 */ (void) unlink_file (backup); if (!isfile (filename)) error (1, 0, "patch original file %s does not exist", *************** *** 1575,1582 **** --- 1622,1635 ---- retcode = 0; else { + #ifdef _WIN32 + /* See above */ + run_setup ("%s -f -s -b .orig %s %s", PATCH_PROGRAM, + filename, temp_filename); + #else run_setup ("%s -f -s -b ~ %s %s", PATCH_PROGRAM, filename, temp_filename); + #endif /* _WIN32 */ retcode = run_exec (DEVNULL, RUN_TTY, RUN_TTY, RUN_NORMAL); } /* FIXME: should we really be silently ignoring errors? */ ============================== cut here ============================== -- Shankar Unni shankar@chromatic.com Chromatic Research (408) 752-9488