bsdtar vs. NFS: Couldn't visit directory: No such file or directory

Tim Kientzle tim at kientzle.com
Wed Nov 26 11:37:30 PST 2008


David Wolfskill wrote:
> Running an 8-core RELENG_7_1/i386 system (updated this morning), trying
> to tar up a directory hierarchy rooted at a directory nnamed "sb2" in a
> file system that is NFS-mounted (exported from a NetApp Filer); I have
> the following logged:
> 
> @ 1227662967 [Tue Nov 25 17:29:27 2008] Starting "tar zcpf sb2.tgz sb2" in /homes/dwolf/bspace
> tar: sb2/src/vendor/berkeley-db/os/CVS: Couldn't visit directory: No such file or directory
>   ...

> * It may be argued that telling tar(1) to go look in a file or
>   directory, then claiming that it doesn't exist, is rather bad form;

Couple of quick notes about what tar is seeing here that
may help diagnose the NFS issue.  First, tar(1) has it's
own directory-traversal code.  Here's how that code works:
  * Tar reads all of the elements of the 'os' directory.
  * As it reads, it calls lstat() on each one.  (stat() would
    have been used if you'd requested a -L logical traversal)
  * Any that are directories ('CVS' in this case) are
    put onto a work queue for later attention
  * At some later point, the 'CVS' entry is popped from
    the work queue and tar invokes chdir("CVS") to visit that
    directory.
  * It then uses opendir(".") to read entries from that
    directory.

A few key points:
  1) An lstat() of the 'CVS' directory here succeeded.
  2) Some time may have elapsed between when the lstat() was
     invoked (and clearly succeeded, else 'CVS' wouldn't
     have been identified as a directory and put onto the
     work queue) and when the chdir() call was made.  That
     may be interacting badly with some underlying cache
     expiration or network variability.
  3) The error here is being triggered by a failed chdir()
     system call.

I hope this helps someone to understand the NFS issue that
you're seeing.

Meanwhile, I'll look at the tar issue.

Thanks very much for reporting this.  This sort of problem
is extremely hard to test for and doesn't get reported very
often when it does occur.

Hmmmmm....  I just noticed that there's currently no
error handling if a chdir("..") operation fails when
you try to ascend back to a parent directory.  I should
probably fix that, too, while I'm in here.

Tim


More information about the freebsd-stable mailing list