bothe@net7.uucp (03/28/90)
Hardware: Nixdorf Targon/35 (Pyramid), Software: TOS 3.3.04
I found an error performing the daily backup with AT&T find/cpio:
if you have directories /a /b /c ... /v
with one of these is (like /n) remote mounted (nfs),
but the remote hosts is down,
the comand "find / -print" will (sometimes) forget other directories to
find, even if they are real (not nfs) mounted filesystems !
find produces the error messages:
find: bad status -- /n
find: bad directory tree
It seems a very serios bug, because the result of find is unpredictable !!!
Is it an error in TOS or OS or a general error in find ?
Is it restricted to find or a general bug (/.attlib/libc.a) ?
what can i do to get correct backup all times ?
(find . does not work correct too);
*************** Richard Bothe, NIXDORF COMPUTER AG, Dep DTSW 2-4 _ / \ _
N I X D O R F Berliner Str. 95, D-8000 Munic (West Germany) \ /
*************** Tel.: +49 89 3601 2956, bothe.muc@nixpbe.UUCP /_ _\
C O M P U T E R {unido!nixpbe, uunet!{nixbur,nixntc}}!bothe.muc \ /cpcahil@virtech.uucp (Conor P. Cahill) (03/28/90)
In article <569@netmuc.UUCP> bothe@net7.uucp writes: > > [description of how find(1) has a problem with remote file systems] > [when the remote system is down deleted] > >It seems a very serios bug, because the result of find is unpredictable !!! No this is not a bug in find. Find should stop when it comes to a read error on a directory/file. A read error is a very bad thing and you shouldn't keep running when you run into one. The problem here is your configuration. Apparently your current configuration is to soft mount NFS file systems onto the local machine. Due to the fact that your remote system can be down you should do one of the following: 1. Hard mount your NFS file systems. This will cause the find to wait until the remote system comes back up before continuing. 2. Unmount the NFS file systems before the remote system is taken down. 3. Write a small test script/program with a timeout that verifies that the NFS file system is up & available before you start the find and change the find directory specifications accordingly. 4. Arrange the find directory list so that the NFS file systems are listed last, so that if the remote system is down you won't loose any local files from the find output. Of course, only the first option will correctly handle the case where the remote file system goes down in the middle of the find. Another option would be to write your own find with appropriate timeouts whenever reading data from the disk, but who has the time? -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170