make_file() could ignore ENODEV errors (from afs filesystem)

Kevin J Walters kjw at ms.com
Wed Jun 19 07:28:02 EST 2002


>>>>> "d" == Dave Dykstra <dwd at bell-labs.com> writes:

d> On Tue, Jun 18, 2002 at 11:43:56AM +0100, Kevin J Walters wrote:
>> 
>> Hi,
>> 
>> Would it be acceptable to patch make_file() in flist.c to ignore any
>> ENODEV's and not mark them as io_error=1?
>> 
>> In afs, a mountpoint to a volume which does not exist gives an
>> ENODEV. As such, it can't be copied, so should (or could) just be
>> ignored?

d> Is this a normal situation in afs (I've never used it)?  Can you use
d> --exclude to skip it?

It's not unheard of. The mount operation is a user level command, so
any user has the potential to create a mountpoint to a volume which
may not exist (ENODEV) or may not be reachable (ETIMEDOUT or just
blocks).

I am using --exclude '.asd/*', this is what comes out,

building file list ... readlink .asd/A: No such device
readlink .asd/B: No such device
readlink .asd/C: No such device
done
IO error encountered - skipping file deletion
wrote 2507 bytes  read 20 bytes  561.56 bytes/sec
total size is 172798  speedup is 68.38
rsync error: partial transfer (code 23) at main.c(578)

so i think the allegation of a 'partial transfer' is not correct
because i did exclude those directories and it did tranfer the
included stuff correctly. --exclude '/*' works but it's a bit too
severe :)

The output doesn't bother me, it's just that exit 23 which is
preventing me checking for real errors.

Could io_error only be set if !check_exclude_file(f, fname, &st) and
maybe leave the rprintf but with a WARNING?

Why is the check_exclude_file() not performed before the
readlink_stat()? This would mean the stat was never attempted (saving
a system call) for an excluded thing (including things that error)?

d> Do you know if there is precedent in other standard open source tools
d> to ignore ENODEV?  In general I don't think it's a good idea to ignore
d> errors.  It might mean something else in a different situation.

Don't know of any precedent. The only error i've seen out of a
filesystem is sunos/solaris ufs EIO when a disk is broken. Not sure
what error a soft NFS mount gives.


regards

|<evin

-- 
Kevin J Walters                      Morgan Stanley
kjw at ms.com, kjw at acm.org              20 Cabot Square
Tel: 020 7425 7886                   Canary Wharf
Fax: 020 7677 8504                   London E14 4QW




More information about the rsync mailing list