[Format recovered--see http://www.lemis.com/email/email-format.html]
> X-Mailer: Microsoft Outlook, Build 10.0.3416 Incorrect wrapping in quoted text. On Monday, 6 January 2003 at 8:45:25 -0500, Phillip Smith wrote: > >> On Saturday, 4 January 2003 at 20:30:52 -0500, Phillip Smith wrote: >>> on 1/4/03 6:50 PM, Stephen Hovey at [EMAIL PROTECTED] wrote: >>>> On Sat, 4 Jan 2003, Phillip Smith wrote: >>>>> Wondering what (if anything) can be done about this? >>>>> >>>>> freedom# tar -xf www.tar >>>>> tar: Skipping to next file header... >>>>> tar: Unknown file type '' for >>>>> 8˟ܫ[+n_}M2žV28(Uvjuש, extracted as normal >file >>>>> tar: Skipping to next file header... >>>>> >>>>> I don't understand what's happened to this archive (and serveral >>>>> others that represent my entire system backup)? I'm having the >>>>> same problem with a whole set of archives that I ftp to a remote >>>>> Windows machine... the ones I stored on my other FreeBSD machine >>>>> are fine. Did something happen during the transfer? >>>> >>>> windows ftp defaults to ascii more, not binary, so its adds a \r >>>> to each \n - you might save your tar files if you upload ascii to >>>> get them stripped out again. >>> >>> Would it be possible to use a script to achieve the same outcome? >> >> No, you don't know which \rs have been added. >> >>> I've tried re-uploading/downlaoding the files in multiple modes, >>> to no avail. >> >> It should work with binary transfer. > > Tried several times/ways to no avail. Hmm. OK, when you've transferred the file, transfer it back to your FreeBSD box under a different name. Then compare the two files with cmp(1). That will tell you whether you're really suffering from data corruption. >>> Also, I ftp'd these files TO a Windows box FROM my BSD box, so I >>> believe that the default mode for that would be binary? >> >> What does ftp say? > > FTP is set to binary by default, so I'm quite confused. Not on Microsoft. >>> Are there any other reasons this may have happened? Any way to test? >> >> I can't think of any other. It's a traditional problem. You >> can test by comparing the size of the archives on each side. > > Archives appear to be the same size on both sides. Hmm, that's not the \r syndrome, then. > I'm starting to think that the archives got corrupted somehow? What does tar t tell you on the FreeBSD side? > The archive starts to unpack (I see a few directories and files) > then hits a snag and spews garbage or quits. > > Here's a question then... suppose I want to re-mount a drive that > had the data on it, but the drive was one of two drives mirrored > with vinum. I've subsequently changed my drive set-up and now this > drive is just sitting there as a 'hot spare', I haven't newfs'd it > or anything... so I presume the data is still on it. If I were to > re-connect the drive, and re-load vinum, could I access the data? > How easy/difficult would this be? That depends a lot on the Vinum configuration and whether you're running any other Vinum volumes. It could work. But first I'd like to establish whether your archive is really corrupt. There's a possibility that the tar you're using on the Microsoft side simply doesn't understand the archive. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
