Store full filenames in header

[GoogleCodeExporter]

I do the following:
   xdelta3 -s /home/csilvers/a/b/c /home/csilvers/e/f/g /home/csilvers/patch

I then delete the 'e' directory tree.  I'd like to reconstitute it by just
applying the patch:
   xdelta3 -d /home/csilvers/patch

But this doesn't work, because the patch file stores the source input as
'c', not as '/home/csilvers/a/b/c' (or even just a/b/c).  Instead I get this:

   % xdelta3 -d patch 
   xdelta3: using default output filename: g
   xdelta3: using default source filename: c
   xdelta3: file open failed: read: c: No such file or directory

Can you add support for storing the full filenames in the vcdiff header,
not just the basename like you do now?  If you're storing the basename for
a particular use-case you don't want to break, perhaps store the full
filename via a flag?

I think the relevant change is to not do the (os-specific) 'basename' in
main_apphead_string, perhaps only when the flag isn't set.  This would mean
the input is stored verbatim, either as an absolute file or relative file,
depending on the commandline args (xdelta3 -s /tmp/foo vs xdelta3 -s
tmp/foo).  An alternative would be to always 'abspathify' the filenames
before storing -- again, only if the appropriate flag is set -- so
'tmp/foo' gets stored as something like '/home/csilvers/tmp/foo'.

(As a minor UI note: right now printhdr prints the filenames like this:
srcfile/dstfile.  With this change, you may want to modify that to
srcfile:dstfile or even srcfile<space>dstfile.)

craig

Original issue reported on code.google.com by csilv...@gmail.com on 10 Jun 2007 at 11:54

[GoogleCodeExporter]

Here's a less invasive alternative to storing full filenames everywhere, which 
would
also be sufficient for my intended use: when there's a source file, store its
filename relative to the output file.  So in the example above, we'd have:
   XDELTA filename (output):     g
   XDELTA filename (source):     ../../a/b/c

Then I'd still have to know somehow to run 'xdelta3 -d patch' from the e/f/
directory, but if I did that everything would work correctly.

Original comment by csilv...@gmail.com on 11 Jun 2007 at 12:06