Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik From: jik@athena.mit.edu (Jonathan I. Kamens) Newsgroups: comp.sources.d Subject: Re: Problems with Patch not creating new files Message-ID: <1991Apr29.032503.237@athena.mit.edu> Date: 29 Apr 91 03:25:03 GMT References: <1991Apr27.150844.5719@telesys.cts.com> Sender: news@athena.mit.edu (News system) Distribution: comp Organization: Massachusetts Institute of Technology Lines: 58 In article <1991Apr27.150844.5719@telesys.cts.com>, kreed@telesys.cts.com (Kevin W. Reed) writes: |> I have the (I believe) latest and greatest version of Patch, |> |> $Header: patch.c,v 2.0.2.0 90/05/01 22:17:50 davison Locked $ |> Patch level: 12u3 I just pulled the source off of jpl-devvax.jpl.nasa.gov, and I assume that those are the most up-to-date, and this is what they say when you run "patch -v": $Header: patch.c,v 2.0.1.6 88/06/22 20:46:39 lwall Locked $ Patch level: 12 It looks to me like someone has made modifications to the version you have. I don't know whether or not those modifications will cause the problems you're having. |> But seem to have problems when a patch file attempts to create a new |> file (compared against /dev/null). The code does not decide whether or not to create a file by checking to see if the old file in the patch is /dev/null. It does so by checking to see if (a) the patch has only one hunk, with "*** 0 ****" as the contents of the original file in the hunk, and (b) the new file named in the patch does not exist. |> After scanning the sources, it seems |> that the code to handle this type of occurance is either missing or |> been obliterated. I found the code that does the checks I mentioned above near the top of the function plan_a() in the file inp.c in the sources. Here's the relevant block: if (ok_to_create_file && stat(filename, &filestat) < 0) { if (verbose) say2("(Creating file %s...)\n",filename); makedirs(filename, TRUE); close(creat(filename, 0666)); } The variable ok_to_create_file is set elsewhere. |> When a new file is encountered, the program simply |> asks for "Filename to Patch: " instead of creating the new module. I don't know why this is happening. Like I said, it could be because whatever changes have been introduced into the version you have, broke the new file functionality. Or, it could be because the patch that's trying to create the new file is broken in some respect. Or, it could be because of a real bug in patch :-). If the code I quoted above does exist in your version, I would suggest you run it under a debugger and step through the plan_a() function and see exactly what's going wrong. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710