here is a patch for gnu tar incremental backup (-g) or (--listed-incremental)

here is a patch for gnu tar incremental backup (-g) or (--listed-incremental)

[George Carrette]

Here is a fix for gnu tar incremental backup feature
for the most recent cygwin that uses a 64-bit value for 
the type ion_t

This was done against the sources in release/tar/tar-1.13.25-3-src.tar.bz2


I am a fair C programmer but have no skill in GNU Autoconfig,
so I did not attempt to define the required "#if" parameters in 
that way. But if you need a quick fix for the -g or --listed-incremental
feature of gnu tar this will do nicely.

I've provided both a regular diff and a patch diff, because regular diff
more clearly shows the minimal changes required.

The fix was quite easy due to a previous message to the cygwin mailing
list where the problem was clearly identified as having to do with
the inon_t size.

-George J. Carrette



===INCREMEN.C.DIFF===

133a134
> 
367a369,381
> #define INO_T_SIZE 8
> #define LONG_SIZE 4
> #if INO_T_SIZE > LONG_SIZE
> #define INON_T unsigned long long
> #define DIRECTORY_FILE_ENTRY_FMT "+%lu %llu %s\n"
> #define STRTOINON strtoull
> #else
> #define INON_T unsigned long
> #define DIRECTORY_FILE_ENTRY_FMT "+%lu %lu %s\n"
> #define STRTOINON strtoul
> #endif
> 
> 
403c417
<       unsigned long u = (errno = 0, strtoul (buf, &ebuf, 10));
---
>       INON_T u = (errno = 0, STRTOINON (buf, &ebuf, 10));
427c441
< 	  dev = u = strtoul (strp, &ebuf, 10);
---
> 	  dev = u = STRTOINON (strp, &ebuf, 10);
439c453
< 	  ino = u = strtoul (strp, &ebuf, 10);
---
> 	  ino = u = STRTOINON (strp, &ebuf, 10);
472a487
> 
474c489
<       fprintf (fp, "+%lu %lu %s\n" + ! directory->nfs,
---
>       fprintf (fp, DIRECTORY_FILE_ENTRY_FMT + ! directory->nfs,
476c491
< 	       (unsigned long) directory->inode_number,
---
> 	       (INON_T) directory->inode_number,


===INCREMEN.C.PATCH=== 
*** incremen.c.old	Sun Oct 26 20:44:33 2003
--- incremen.c	Mon Oct 27 06:24:18 2003
*************** note_directory (char const *name, dev_t 
*** 131,136 ****
--- 131,137 ----
    size_t size = offsetof (struct directory, name) + strlen (name) + 1;
    struct directory *directory = xmalloc (size);
  
+ 
    directory->device_number = dev;
    directory->inode_number = ino;
    directory->children = CHANGED_CHILDREN;
*************** get_directory_contents (char *path, dev_
*** 365,370 ****
--- 366,384 ----
    }
  }
  \f
+ #define INO_T_SIZE 8
+ #define LONG_SIZE 4
+ #if INO_T_SIZE > LONG_SIZE
+ #define INON_T unsigned long long
+ #define DIRECTORY_FILE_ENTRY_FMT "+%lu %llu %s\n"
+ #define STRTOINON strtoull
+ #else
+ #define INON_T unsigned long
+ #define DIRECTORY_FILE_ENTRY_FMT "+%lu %lu %s\n"
+ #define STRTOINON strtoul
+ #endif
+ 
+ 
  static FILE *listed_incremental_stream;
  
  void
*************** read_directory_file (void)
*** 400,406 ****
        char *ebuf;
        int n;
        long lineno = 1;
!       unsigned long u = (errno = 0, strtoul (buf, &ebuf, 10));
        time_t t = u;
        if (buf == ebuf || (u == 0 && errno == EINVAL))
  	ERROR ((0, 0, "%s:1: %s", quotearg_colon (listed_incremental_option),
--- 414,420 ----
        char *ebuf;
        int n;
        long lineno = 1;
!       INON_T u = (errno = 0, STRTOINON (buf, &ebuf, 10));
        time_t t = u;
        if (buf == ebuf || (u == 0 && errno == EINVAL))
  	ERROR ((0, 0, "%s:1: %s", quotearg_colon (listed_incremental_option),
*************** read_directory_file (void)
*** 424,430 ****
  	    buf[n - 1] = '\0';
  
  	  errno = 0;
! 	  dev = u = strtoul (strp, &ebuf, 10);
  	  if (strp == ebuf || (u == 0 && errno == EINVAL))
  	    ERROR ((0, 0, "%s:%ld: %s",
  		    quotearg_colon (listed_incremental_option), lineno,
--- 438,444 ----
  	    buf[n - 1] = '\0';
  
  	  errno = 0;
! 	  dev = u = STRTOINON (strp, &ebuf, 10);
  	  if (strp == ebuf || (u == 0 && errno == EINVAL))
  	    ERROR ((0, 0, "%s:%ld: %s",
  		    quotearg_colon (listed_incremental_option), lineno,
*************** read_directory_file (void)
*** 436,442 ****
  	  strp = ebuf;
  
  	  errno = 0;
! 	  ino = u = strtoul (strp, &ebuf, 10);
  	  if (strp == ebuf || (u == 0 && errno == EINVAL))
  	    ERROR ((0, 0, "%s:%ld: %s",
  		    quotearg_colon (listed_incremental_option), lineno,
--- 450,456 ----
  	  strp = ebuf;
  
  	  errno = 0;
! 	  ino = u = STRTOINON (strp, &ebuf, 10);
  	  if (strp == ebuf || (u == 0 && errno == EINVAL))
  	    ERROR ((0, 0, "%s:%ld: %s",
  		    quotearg_colon (listed_incremental_option), lineno,
*************** write_directory_file_entry (void *entry,
*** 470,479 ****
    if (directory->found)
      {
        int e;
        char *str = quote_copy_string (directory->name);
!       fprintf (fp, "+%lu %lu %s\n" + ! directory->nfs,
  	       (unsigned long) directory->device_number,
! 	       (unsigned long) directory->inode_number,
  	       str ? str : directory->name);
        e = errno;
        if (str)
--- 484,494 ----
    if (directory->found)
      {
        int e;
+ 
        char *str = quote_copy_string (directory->name);
!       fprintf (fp, DIRECTORY_FILE_ENTRY_FMT + ! directory->nfs,
  	       (unsigned long) directory->device_number,
! 	       (INON_T) directory->inode_number,
  	       str ? str : directory->name);
        e = errno;
        if (str)
=========================================

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

New tar available for testing (was Re: here is a patch for gnu tar incremental backup...)

[Christopher Faylor]

On Mon, Oct 27, 2003 at 06:45:32AM -0500, George Carrette wrote:
>Here is a fix for gnu tar incremental backup feature
>for the most recent cygwin that uses a 64-bit value for 
>the type ion_t
>
>This was done against the sources in release/tar/tar-1.13.25-3-src.tar.bz2

Thanks for the patch but I don't think it is quite right and I don't think
it catches everything.

I'm uploading a new version of tar for testing now.  I'd appreciate feedback
(to the cygwin list) on whether it solves the reported problem.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New tar available for testing (was Re: here is a patch for gnu tar incremental backup...)

[Christopher Faylor]

On Mon, Nov 10, 2003 at 01:25:02PM +0000, Jeremy Green wrote:
>I.e. files/foo/bar is backed-up even though it hasn't changed. With the
>application of the following patch to the tar-1.13.25-4 source package:
>
>--- src/incremen.c.orig 2003-11-10 12:27:36.094206400 +0000
>+++ src/incremen.c      2003-11-10 12:33:06.629492800 +0000
>@@ -437,7 +437,7 @@ read_directory_file (void)
>
>          errno = 0;
> #ifdef __CYGWIN_USE_BIG_TYPES__
>-         ino = strtoul (strp, &ebuf, 10);
>+         ino = strtoull (strp, &ebuf, 10);
> #else
>          ino = strtoul (strp, &ebuf, 10);
> #endif

Odd.  I already have that change in my sandbox already but I must have
made the change after uploading the file.  I'll refresh the source and
binaries shortly.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New tar available for testing (was Re: here is a patch for gnu tar incremental backup...)

[Jeremy Green]

On Sat, Nov 8, 2003 cgf wrote:

> Thanks for the patch but I don't think it is quite right and I don't
> think it catches everything.
>
> I'm uploading a new version of tar for testing now.  I'd appreciate
> feedback (to the cygwin list) on whether it solves the reported problem.

The binary you've uploaded, and the binary I built from the new source
exhibit the same problem that tar-1.13.25-3 showed:

$ touch f1
$ mkdir foo
$ touch foo/bar
$ ls -lR files/
files/:
total 0
-rw-r--r--    1 jeremy    None            0 Nov 10 12:26 f1
drwxr-xr-x+   2 jeremy    None            0 Nov 10 12:26 foo

files/foo:
total 0
-rw-r--r--    1 jeremy    None            0 Nov 10 12:26 bar
$ /usr/src/tar-1.13.25-4/src/tar --verbose --listed-incremental=list \
-cf archive.tar files
/usr/src/tar-1.13.25-4/src/tar: files/foo: Directory is new
files/
files/foo/
files/f1
files/foo/bar
$ /usr/src/tar-1.13.25-4/src/tar --verbose
--listed-incremental=list -cf archive.tar files
/usr/src/tar-1.13.25-4/src/tar: files/foo: Directory has been renamed
files/
files/foo/
files/foo/bar

I.e. files/foo/bar is backed-up even though it hasn't changed. With the
application of the following patch to the tar-1.13.25-4 source package:

--- src/incremen.c.orig 2003-11-10 12:27:36.094206400 +0000
+++ src/incremen.c      2003-11-10 12:33:06.629492800 +0000
@@ -437,7 +437,7 @@ read_directory_file (void)

          errno = 0;
 #ifdef __CYGWIN_USE_BIG_TYPES__
-         ino = strtoul (strp, &ebuf, 10);
+         ino = strtoull (strp, &ebuf, 10);
 #else
          ino = strtoul (strp, &ebuf, 10);
 #endif

The test works as expected:

$ rm list
$ /usr/src/tar-1.13.25-4/src/tar --verbose \
--listed-incremental=list -cf archive.tar files
/usr/src/tar-1.13.25-4/src/tar: files/foo: Directory is new
files/
files/foo/
files/f1
files/foo/bar
$ cat list
1068469530
+3160087061 8677873531989524896 files/foo
$ /usr/src/tar-1.13.25-4/src/tar --verbose \
--listed-incremental=list -cf archive.tar files
files/
files/foo/

However, if I use the tar-1.13.25-1 binary using this list file, I get...

$ cygcheck -c tar
Cygwin Package Information
Package              Version        Status
tar                  1.13.25-1      OK
$ tar --verbose --listed-incremental=list -cf archive.tar files
tar: list:2: Device number out of range
tar: list:2: Inode number out of range
tar: files/foo: Directory has been renamed
files/
files/foo/
files/foo/bar
tar: Error exit delayed from previous errors
$ tar --verbose --listed-incremental=list -cf archive.tar files
files/
files/foo/
ichthus$ cat list
1068469660
23317 2020475296 files/foo

i.e. different inode and device numbers are stored in the list file by
tar-1.13.25-1 and the patched version of tar-1.13.25-4. This doesn't
really matter as far as I'm concerned.

Jeremy

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/