Date: Wed, 26 Nov 2008 11:05:35 -0800 From: Tim Kientzle <tim@kientzle.com> To: David Wolfskill <david@catwhisker.org> Cc: stable@freebsd.org Subject: Re: bsdtar vs. NFS: Couldn't visit directory: No such file or directory Message-ID: <492D9DFF.8050407@kientzle.com> In-Reply-To: <20081126021551.GA83287@bunrab.catwhisker.org> References: <20081126021551.GA83287@bunrab.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?492D9DFF.8050407>