Cannot savedir: Not a directory

[Jean-Louis Martineau-2]

A user get this error when doing incremental backup:
  /bin/tar: ./opt/novell/nss/mnt/.pools/DATA: Cannot savedir: Not a
directory

He is using '--ignore-failed-read', why tar exit with code 2?

This directory is strange, a size of 0 and 1 link:

$ stat /opt/novell/nss/mnt/.pools/DATA
  File: `/opt/novell/nss/mnt/.pools/DATA'
  Size: 0               Blocks: 0          IO Block: 4096   directory
Device: fd08h/64776d    Inode: 127         Links: 1
Access: (0000/d---------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-07-31 07:29:58.270585641 -0500
Modify: 2009-07-31 07:29:58.270585641 -0500
Change: 2009-07-31 07:29:58.270585641 -0500

It is Novell Storage Services//
<http://en.wikipedia.org/wiki/Novell_Storage_Services> (NSS).

The parent is on different filesystem:

stat /opt/novell/nss/mnt/.pools
  File: `/opt/novell/nss/mnt/.pools'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fd05h/64773d    Inode: 1556530     Links: 3
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-12 00:05:21.000000000 -0500
Modify: 2009-07-17 19:54:39.000000000 -0500
Change: 2009-07-29 15:39:22.000000000 -0500

He also use the '--one-file-system' option, why tar try to do a savedir
on the directory if it is on a different filesystem?
The attached path delay the call to savedir until it is needed.
I havent tested it on the user system, I want to know if it break
something before sending it to the user.

Jean-Louis


diff --git a/src/incremen.c b/src/incremen.c
index bb2ba2f..6da029a 100644
--- a/src/incremen.c
+++ b/src/incremen.c
@@ -691,7 +691,7 @@ makedumpdir (struct directory *directory, const char *dir)
 struct directory *
 scan_directory (char *dir, dev_t device, bool cmdline)
 {
-  char *dirp = savedir (dir); /* for scanning directory */
+  char *dirp = NULL; /* for scanning directory */
   char *name_buffer; /* directory, `/', and directory member */
   size_t name_buffer_size; /* allocated size of name_buffer, minus 2 */
   size_t name_length; /* used length in name_buffer */
@@ -699,8 +699,6 @@ scan_directory (char *dir, dev_t device, bool cmdline)
   struct directory *directory;
   char ch;
   
-  if (! dirp)
-    savedir_error (dir);
 
   name_buffer_size = strlen (dir) + NAME_FIELD_SIZE;
   name_buffer = xmalloc (name_buffer_size + 2);
@@ -714,7 +712,6 @@ scan_directory (char *dir, dev_t device, bool cmdline)
            children = CHANGED_CHILDREN;
  but changed to: */
       free (name_buffer);
-      free (dirp);
       return NULL;
     }
 
@@ -730,6 +727,13 @@ scan_directory (char *dir, dev_t device, bool cmdline)
       name_buffer[++name_length] = 0;
     }
 
+  if (directory->children != NO_CHILDREN)
+    {
+      dirp = savedir (dir);
+      if (! dirp)
+        savedir_error (dir);
+    }
+
   if (dirp && directory->children != NO_CHILDREN)
     {
       char *entry; /* directory entry being scanned */

[Sergey Poznyakoff-2]

Hi Jean-Louis,

To begin with, let me ask you what version of GNU tar it is?

> A user get this error when doing incremental backup:
>  /bin/tar: ./opt/novell/nss/mnt/.pools/DATA: Cannot savedir: Not a
> directory
>
> He is using '--ignore-failed-read', why tar exit with code 2?

This option affects only failed reads from the archive, but it does
not affect failed chdir/opendir/readdir calls.

> This directory is strange, a size of 0 and 1 link:
>
> $ stat /opt/novell/nss/mnt/.pools/DATA
>  File: `/opt/novell/nss/mnt/.pools/DATA'
>  Size: 0               Blocks: 0          IO Block: 4096   directory
> Device: fd08h/64776d    Inode: 127         Links: 1
> Access: (0000/d---------)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2009-07-31 07:29:58.270585641 -0500
> Modify: 2009-07-31 07:29:58.270585641 -0500
> Change: 2009-07-31 07:29:58.270585641 -0500

Strange, indeed. Most probably, it's opendir that's failed on it.

> He also use the '--one-file-system' option, why tar try to do a
> savedir on the directory if it is on a different filesystem?

It needed to save the meta-data of this directory, anyway.

> The attached path delay the call to savedir until it is needed.
> I havent tested it on the user system, I want to know if it break
> something before sending it to the user.

From the first glance, it should not break anything. But I doubt
if it should help in this case, either.

Regards,
Sergey

[Jean-Louis Martineau-2]

Hi Sergey,

I don't know what GNU tar version he is using.
The problem is the exit code of 2, amanda think the backup is a failure
in this case. Maybe calling savedir_diag instead of savedir_error should
ifx it.
It's probably an opendir failure, ls report the same "Not a directory"
error.
I will ask the user to try a tar-1.22 and a patched tar. I will let you
know the result.

Thanks,
Jean-Louis

Sergey Poznyakoff wrote:

> Hi Jean-Louis,
>
> To begin with, let me ask you what version of GNU tar it is?
>
>  
>> A user get this error when doing incremental backup:
>>  /bin/tar: ./opt/novell/nss/mnt/.pools/DATA: Cannot savedir: Not a
>> directory
>>
>> He is using '--ignore-failed-read', why tar exit with code 2?
>>    
>
> This option affects only failed reads from the archive, but it does
> not affect failed chdir/opendir/readdir calls.
>
>  
>> This directory is strange, a size of 0 and 1 link:
>>
>> $ stat /opt/novell/nss/mnt/.pools/DATA
>>  File: `/opt/novell/nss/mnt/.pools/DATA'
>>  Size: 0               Blocks: 0          IO Block: 4096   directory
>> Device: fd08h/64776d    Inode: 127         Links: 1
>> Access: (0000/d---------)  Uid: (    0/    root)   Gid: (    0/    root)
>> Access: 2009-07-31 07:29:58.270585641 -0500
>> Modify: 2009-07-31 07:29:58.270585641 -0500
>> Change: 2009-07-31 07:29:58.270585641 -0500
>>    
>
> Strange, indeed. Most probably, it's opendir that's failed on it.
>
>  
>> He also use the '--one-file-system' option, why tar try to do a
>> savedir on the directory if it is on a different filesystem?
>>    
>
> It needed to save the meta-data of this directory, anyway.
>
>  
>> The attached path delay the call to savedir until it is needed.
>> I havent tested it on the user system, I want to know if it break
>> something before sending it to the user.
>>    
>
> From the first glance, it should not break anything. But I doubt
> if it should help in this case, either.
>
> Regards,
> Sergey
>