[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 
>>>>> 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

>>> 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.

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

Reply via email to