And another weird patch corner case.

[Rob Landley]

I upgraded from LFS 6.6 to LFS 6.7, and the need for fuzz factor went away.  
(They rebased the patches.)  But now there's this:

Submitted By:            Bruce Dubbs <bdubbs_at_linuxfromscratch_dot_org>
Date:                    2010-05-02
Initial Package Version: 1.22
Upstream Status:         Submitted
Origin:                  http://wiki.linuxfromscratch.org/lfs/ticket/2651
Description:             Fixes a buffer overflow when creating archives
                         when built by gcc-4.5

diff -urNp tar-1.22-orig/src/create.c tar-1.22/src/create.c
--- tar-1.22-orig/src/create.c   2009-07-09 18:38:37.000000000 +0200
+++ tar-1.22/src/create.c  2009-07-09 18:43:44.000000000 +0200
@@ -578,7 +578,10 @@ write_gnu_long_link (struct tar_stat_inf

The "date" field after filenames is optional, it doesn't have to be there, but 
if it _is_ there, it's supposed to start with a tab.  And, as with makefiles, 
it _cares_ that it's a tab character, not spaces.

But in this file, between "create.c" and 2009, there are spaces, not tabs.  And 
the current gnu-gnu-gnu-dammit project's version of diff is accepting it.

Sigh.

  mkdir temp temp2
  echo hello > temp/"one   two"
  echo walrus > temp2/"one   two"
  diff -ru temp temp2

No special escaping of three consecutive space characters.

Note that the date specification itself has spaces in it.  So it's not just a 
question of grabbing the last whitespace-delimited blob...  (How do they 
handle a file that _ends_ with a space character?)

I suppose I can start at the end of the line and stop at the first run of more 
than one space character.  Assuming having just _one_ space between the name 
and the date isn't allowed...

HA!  The gnu version of patch can't apply the diff the above snippet creates!  
It tries to patch the file "one".  It doesn't support spaces in filenames!  They 
were so clever with their heuristics they broke the thing.  (Gee, where have I 
heard _that_ before...)

Right, _my_ heuristic approach to handling this would be to start at the end 
of the line, work backwards to the last whitespace character occurring before 
a digit immediately followed by a dash (dash before digit happens in timezone, 
but digit before dash only happens in the initial date string), and if you hit 
anything other than a digit, minus, period, or colon, there was no date 
string, only Zuul.

But the question is whether it's worth doing this, since a whitespace damaged 
patch is a BAD THING and you generally want to KNOW about it...

Grr.  Figuring out how to implement some specific behavior is easy.  Figuring 
out what these commands should _do_ is hard.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.