This is a discussion on Re: verifying that unzipped directories are the same? (tar problems) within the Linux Operating System forums, part of the Unix Operating Systems category; --> "idiotprogrammer" <idiotprogrammer@gmail.com> wrote > > Hi, there, I am moving my website from one linux server to another. > ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| "idiotprogrammer" <idiotprogrammer@gmail.com> wrote > > Hi, there, I am moving my website from one linux server to another. > > I have basically been gzipping the tar file, scp to the new site and > there it is. > > But I'm having problems when untarring at the other end. > > I'm getting some error messages. They may be harmless, but I don't > know. > > Here's my main problem. How can I compare a directory with about > 20,000 files and subdirectories inside to make sure everything is > basically there in the unzipped version? > > Is there an easy way to find out some stats on one directory. > (number > of files, directories, total size etc). > > I'm acting under the assumption that the main problem would be > missing > files or directories or that the unzip process stopped unzipping > things when it reached the error message. So really what I need to > find is how many files made it and the paths of those that didn't. > > the end of my screen messages for the tgz were for some media files. > Any help would be appreciated. > > I can remove the last few media files and trying zipping/unzipping > again. But the gzip file is already about 800 mb already. I don't > want > to keep doing this only to find out there are 100s of files giving > problems. > > Robert Nagle > > > teleread/StGregorysTestAudio.wav > teleread/telepodSadi16August2005.wav > teleread/valleygirl.wav > teleread/BLOSSOM-JOHN 2.9.06.wma > teleread/Juliet2.wma > teleread/LCdavidpresentation.wma > > gzip: stdin: unexpected end of file > tar: Unexpected EOF in archive > tar: Unexpected EOF in archive > tar: Error is not recoverable: exiting now > [rjnagle@web27 27test]$ ls Did the tar command complete successfully on the source machine? If it did so at least twice then you may have some sort of version conflict - the version untaring seems to trip over something in the archive. Alternatively you may have some sort of error on the source box - a memory or disk space constraint which is creating the bogus EOF. I guess the same sort of constraint could cause a phantom EOF during untar, actually. Sorry, it's difficult to be more specific. If the tar command is fine, try unpacking the archive on a different machine. That will tell you whether the problem is with the archive or with the destination box. CC |