patch 2.5.4 bug (new files and --strip)

[Nathan Kurz]

I've come across what I feel is a bug in patch.  It occurs when new
files are created when using the -p (strip) option and the original
pathname is longer than the new pathname.  In this case, the new file
is created one level higher in the hierarchy than it ought to be.

For example, assume the diff file:

------------------------------------------------------------------------
diff -urN orig/subdir/old_file subdir/old_file
--- orig/subdir/old_file        Fri Nov 10 20:34:30 2000
+++ subdir/old_file     Fri Nov 10 20:35:28 2000
@@ -1 +1,2 @@
 old
+add
diff -urN orig/subdir/new_file subdir/new_file
--- orig/subdir/new_file        Wed Dec 31 18:00:00 1969
+++ subdir/new_file     Fri Nov 10 20:35:33 2000
@@ -0,0 +1 @@
+new
-------------------------------------------------------------------------

If we run 'patch -p1 < test.diff' above a directory 'subdir' which
contains a file 'old' (which contains the word 'old') but no file
'new', we find that 'old' is appended to properly, but that 'new' is
created at the same level as 'subdir' rather than inside it.

Unfortunately for an easy fix, this seems to agree with documented
rules by which path chooses and strips filenames.  I'm questioning
those rules, since when I run 'diff' it creates files which when run
through 'patch' do not correctly recreate the directory structure.

The existing rules always prefer the name of an existing file, after
directory structures are stripped.  This is good.  If no named file
exists, the 'best file' is chosen.  Currently, the path with fewer
components is always prefered.  This is not always good.

Instead, I think that since we are about to create a file anyway, we
should strip the filename and check to see if either directory exists.
If one does, choose it.  If both do, choose the longer.  I think this
would be more likely to put new files in the correct location.

--nate

ps.  This actually did come about because of a real world problem.