Date: Thu, 9 Jan 2003 10:22:48 -0500 From: "Phillip Smith" <phillip@3bags.com> To: "'Greg 'groggy' Lehey'" <grog@FreeBSD.org> Cc: <freebsd-questions@FreeBSD.ORG> Subject: RE: help! Problems with TAR archives? Message-ID: <002401c2b7f2$f7ba5e30$aeb423cf@3bagsmedia> In-Reply-To: <20030107005454.GF2279@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Greg 'groggy' Lehey [mailto:grog@FreeBSD.org] >=20 > [Format recovered--see http://www.lemis.com/email/email-format.html] >=20 > > X-Mailer: Microsoft Outlook, Build 10.0.3416 >=20 > Incorrect wrapping in quoted text. Argh! I thought I had fixed that... I've set the wrap to 132, what else can I do? Perhaps I'll try one of these third-party programs? Or switch to ??? at the office for email? >=20 > 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 shovey@buffnet.net 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 > >>>>> = =97=E7=D3=EE=EF=E68=CB=9F=DC=AB=BB=DF[+=EE=AFn=B7=D1_}=FB=8F=86=ED=D2M=C2= 2=C5=BE=F0=90=B1=E7=D5V=B42=AC=A38(Uvj=DBu=BE=DF=D7=A9=A6=85=E4,=20 > >>>>> 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=20 > 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. >=20 > Hmm. OK, when you've transferred the file, transfer it back > to your FreeBSD box under a different name. Then compare the=20 > two files with cmp(1). That will tell you whether you're=20 > really suffering from data corruption. Okay, I'll give that a try. >=20 > >>> 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. >=20 > Not on Microsoft. True. >=20 > >>> 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. >=20 > Hmm, that's not the \r syndrome, then. >=20 > > I'm starting to think that the archives got corrupted somehow? >=20 > What does tar t tell you on the FreeBSD side? tar: Hmm, this doesn't look like a tar archive. tar: Skipping to next file header... tar: only read 521 bytes from archive etc.rein.tar Also, I tried re-creating the problem. Exact same scenario. Created a new TAR archive, ftp'd from FreeBSD to Window (not specifying a setting), then used 'get' to bring them back to FreeBSD and the archives are fine. So, I'm thinking that the original archives are corrupt... >=20 > > 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=20 > 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=20 > > re-connect the drive, and re-load vinum, could I access the=20 > data? How > > easy/difficult would this be? >=20 > That depends a lot on the Vinum configuration and whether > you're running any other Vinum volumes. It could work. But=20 > first I'd like to establish whether your archive is really=20 > corrupt. There's a possibility that the tar you're using on=20 > the Microsoft side simply doesn't understand the archive. I'm using TAR on the FreeBSD side, not the Microsoft side. Don't have an archiver installed on the Windows box. I don't have any Vinum volumes set up at the moment, no. But, I was thinking I could plug in the 'hot spare' drive and start vinum and see what config it pulls from the drive; then alter the config so that there's only one subdisk (the hot spare) for the 'mirror' and mount that and move the data off? What do you think? >=20 > Greg > -- > When replying to this message, please copy the original > recipients. If you don't, I may ignore the reply or reply to=20 > the original recipients. For more information, see=20 http://www.lemis.com/questions.html See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002401c2b7f2$f7ba5e30$aeb423cf>