!head head -c 512 powem12242005.tar.recovered powem/#org_b_ahome_acgaw_apublic__html_alayout.html#0000600000175000001440000000000010343042116026673 0ustar powemusers00000000000000 Thanks. mp -- Michael Powe org Naugatuck CT USA "The secret to strong security: less reliance on secrets." -- Whitfield Diffie [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => <87fyobl8u0.fsf@ellen.trollope.org> [ref] => <1135699040.539482.195940@g14g2000cwa.googlegroups.com> [htmlstate] => on_nl2br [postusername] => Michael [ip] => michael+gnus@tr [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 16 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) --> !head >head -c 512 powem12242005.tar.recovered >powem/#org_b_ahome_acgaw_apublic__html_alayout.html#0000600000175000001440000000000010343042116026673 0ustar powemusers00000000000000[/ref] In the olden days, man 5 tar would get you an explanation of the tar header. This seems to be gone from anything touched by GNU. Maybe you can find some other flavor of Unix system to look at. Or read the source for GNU tar to get some clues. carl -- carl lowenstein marine physical lab u.c. san diego edu [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => [ref] => <1135699040.539482.195940@g14g2000cwa.googlegroups.com> <87fyobl8u0.fsf@ellen.trollope.org> [htmlstate] => on_nl2br [postusername] => Carl [ip] => cdl@deeptow.ucs [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 18 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) --> !head >>head -c 512 powem12242005.tar.recovered >>powem/#org_b_ahome_acgaw_apublic__html_alayout.html#0000600000175000001440000000000010343042116026673 0ustar powemusers00000000000000[/ref][/ref] [ref] >In the olden days, man 5 tar would get you an explanation of the tar header. >This seems to be gone from anything touched by GNU.[/ref] [ref] >Maybe you can find some other flavor of Unix system to look at. Or read >the source for GNU tar to get some clues.[/ref] man 5 tar on a FreeBSD system will list the tar structures for four different tar implementations going back to the original tar, ustar [Unix standard tar], gnutar, and one for spare-headers. Bill -- Bill Vermillion - bv @ wjv . com [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => [ref] => <87fyobl8u0.fsf@ellen.trollope.org> [htmlstate] => on_nl2br [postusername] => Bill [ip] => bv@wjv.com [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 19 [islastshown] => [isfirstshown] => [attachments] => [allattachments] => ) --> rescue damaged tar file - Linux / Unix Administration

rescue damaged tar file - Linux / Unix Administration

I have a compressed archive that I created using GNU tar on a gentoo system. The tar file is about 900 MB compressed and about 2.5 GB uncompressed. This archive has bad data about 1/3 to 1/2 way through it. I'm trying to find a way to get at the data below the damaged part. At the point of failure, tar reports: tar: skipping to next header tar: archive contains obsolescent base-64 headers tar: error exit delayed from previous errors I used the gzip recovery kit to unpack the file. This worked and gave me the 2.5 GB uncompressed file. ...

  1. #1

    Default rescue damaged tar file


    I have a compressed archive that I created using GNU tar on a gentoo
    system. The tar file is about 900 MB compressed and about 2.5 GB
    uncompressed.

    This archive has bad data about 1/3 to 1/2 way through it. I'm trying
    to find a way to get at the data below the damaged part. At the point
    of failure, tar reports:

    tar: skipping to next header
    tar: archive contains obsolescent base-64 headers
    tar: error exit delayed from previous errors

    I used the gzip recovery kit to unpack the file. This worked and gave
    me the 2.5 GB uncompressed file. However, tar will only unpack up to
    the damaged part, and even with --ignore-failed-read, s up.

    cpio will not work, I tried this on the uncompressed file:

    cpio -F tarfilename -i -v

    The error returned is:

    cpio: standard input is closed: Value too large for defined data type.

    I have googled high and low and cannot find a relevant explanation of
    the error in this context nor any resolution.

    The same message is returned for

    cpio -ird -H tar < tarfilename

    I also tried the recovery kit's option to split the recovered file at
    the point of corruption and save the "good" parts. However, it
    doesn't split the file, it generates a message that says "bad data at
    byte abc" immediately followed by "good data at byte abc" and then
    keeps going, returning a single file.

    Finally, I copied the file to a windows machine and opened it in
    winzip, but winzip only opens it up to the point of corruption.

    If anyone can tell me how I can recover this data, I will be eternally
    grateful. I have looked at the "Advanced Tar Repair" tool, but of
    course, I would like to avoid shelling out that kind of money for a
    one-off. This is the only time I have had this problem in 8 years of
    using tar, and I fully expect I could go that long again.

    Thanks.

    mp

    --
    'cat' is not recognized as an internal or external command,
    operable program or batch file.
    Michael Guest

  2. #2

    Default Re: rescue damaged tar file

    [followup set to comp.unix.admin only]

    In comp.unix.admin Michael Powe <michael+org> wrote:

    | I have a compressed archive that I created using GNU tar on a gentoo
    | system. The tar file is about 900 MB compressed and about 2.5 GB
    | uncompressed.
    |
    | This archive has bad data about 1/3 to 1/2 way through it. I'm trying
    | to find a way to get at the data below the damaged part. At the point
    | of failure, tar reports:

    [etc]

    Possibly the damage is in a form that effects the relative offset of the
    data, for example the addition or deletion of an amount of data that is
    not a multiple of 512 bytes. What a tar recovery program would have to
    do is look for what appears to be a valid tar header using every level of
    byte offset to find something. Assuming only one point of corruption,
    this might be doable from the end of the file working in reverse to the
    front. What is the exact number of bytes of the uncompressed copy?

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  3. #3

    Default Re: rescue damaged tar file

    >>>>> "phil" == phil-news-nospam <net> writes:

    phil> [followup set to comp.unix.admin only]
    phil> In comp.unix.admin Michael Powe <michael+org> wrote:

    phil> | I have a compressed archive that I created using GNU tar
    phil> on a gentoo | system. The tar file is about 900 MB
    phil> compressed and about 2.5 GB | uncompressed.
    phil> |
    phil> | This archive has bad data about 1/3 to 1/2 way through it.
    phil> I'm trying | to find a way to get at the data below the
    phil> damaged part. At the point | of failure, tar reports:

    phil> [etc]

    phil> Possibly the damage is in a form that effects the relative
    phil> offset of the data, for example the addition or deletion of
    phil> an amount of data that is not a multiple of 512 bytes. What
    phil> a tar recovery program would have to do is look for what
    phil> appears to be a valid tar header using every level of byte
    phil> offset to find something. Assuming only one point of
    phil> corruption, this might be doable from the end of the file
    phil> working in reverse to the front. What is the exact number
    phil> of bytes of the uncompressed copy?

    1010083339 2005-12-24 15:44 powem12242005.tar.gz
    2469939203 2005-12-25 20:41 powem12242005.tar.recovered

    The "recovered" file is generated by gzrecover from GNU Recovery Tool Kit
    (http://www.urbanophile.com/arenn/coding/gzrt/gzrt.html). Standard
    gzip will not unpack the file and exits with a CRC error.

    BTW, if I had some pointers on yzing these tar files, I have some
    knowledge of Java and perl and I'd be willing to spend some time
    trying to "reverse engineer" the file, so to speak. I have no
    experience handling binary files in that manner, though.

    Thanks.

    mp


    --
    Michael Powe org Waterbury CT
    ENOSIG: signature file is empty
    Michael Guest

  4. #4

    Default Re: rescue damaged tar file

    Michael Powe wrote: 

    I think you can forget about it. Modern compressors operate by
    specifying a position and length of previous data to copy as new
    data, using a window of from 4k to 64k or more into the old data
    (measured from the point of expansion). Once the data is fouled
    that reference is gone, and there is no way to recover.

    The same applies to LZW compression, although the mechanism is
    different. There there is a remote chance that the compressor has
    detected a poor compression ratio and decided to reinitialize its
    tables, in which case some recovery would be possible. However
    that mechanism hasn't been used seriously for 20 years or so, due
    to patent problems.

    That is one advantage of the zip format, i.e. each individual
    compressed file stands alone, so an error will only lose one file.
    With the tar format all files are basically concatenated into
    one, and the result may then be compressed.

    To avoid this sort of foul up in the future, you would be well
    advised to insist on ECC memory in all your systems.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Chuck Guest

  5. #5

    Default Re: rescue damaged tar file


    Michael Powe wrote: 

    Google gives me hits on 'tar file recovery'.
    The first one I looked at was commercial but seemed to have
    a demo package.

    I'd also try Shilling's 'star':

    http://freshmeat.net/projects/star
    Dan Guest

  6. #6

    Default Re: rescue damaged tar file


    I have looked at the various 'google' options but without joy. The
    "Advanced Tar Recover" tool failed.

    Thanks.

    mp
    Michael Guest

  7. #7

    Default Re: rescue damaged tar file

    On Mon, 26 Dec 2005 11:40:26 -0500, Michael Powe wrote:
     

    Best option is to make absolutely certain that you can't get the damaged
    section of the data back - if the reason for the corruption is due to the
    source media (tape or disk say) then there are sometimes options there to
    recover bad data...

    And in the future, don't compress archives of anything critical, just
    because of potential problems like this :(

    cheers

    Jules

    Jules Guest

  8. #8

    Default Re: rescue damaged tar file

    Jules wrote (in part):
     
    How do tape drives that do _hardware compression_ get around this problem?

    I imagine they compress one block at a time. On my tape drives, they have a
    2 Megabyte buffer in the drive, and it normally writes 65536-byte blocks to
    the tape. They employ a 4 layer Reed Solomon error detection and correction
    scheme, and use what they call Adaptive Lossless Data Compression (whatever
    that is). I am also not sure what "4 layer Reed Solomon error detection and
    correction" is. I know they do lateral and longitudinal and diagonal parity
    checking of each block. Reed Solomon technique is well known, but I do not
    know what the 4-layer is all about.

    http://www.siam.org/siamnews/mtc/mtc193.htm

    I always have hardware compression on (it is the default for the drive), and
    have never lost anything. But that is 2 data points (2 drives).

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 16:00:00 up 30 days, 2:32, 5 users, load average: 4.30, 4.23, 3.98
    Jean-David Guest

  9. #9

    Default Re: rescue damaged tar file

    >>>>> "Jules" == Jules <this.yahoo.co.uk> writes:

    Jules> On Mon, 26 Dec 2005 11:40:26 -0500, Michael Powe wrote: [/ref]

    Jules> Best option is to make absolutely certain that you can't
    Jules> get the damaged section of the data back - if the reason
    Jules> for the corruption is due to the source media (tape or disk
    Jules> say) then there are sometimes options there to recover bad
    Jules> data...

    I have two copies of the archive, on two machines. (Both slackware
    linux 10.2.) It exhibits the same behavior and file sizes on both
    machines.

    Jules> And in the future, don't compress archives of anything
    Jules> critical, just because of potential problems like this :(

    Yes, I'd gone so long without any problems that I was y. I
    created the archive, scp'ed it to the other machine and blew away the
    original. Because there was no problem with creating the archive, I
    did not even think about a simple 'tar ztf' before proceeding. My bad
    there, for sure.

    Very frustrating. I've spent most of the day recreating the most
    important configuration files that are "lost" in that archive. I
    found an old, old backup so I didn't have to go back to scratch, but
    still it is tedious. Good thing my wife is out all day doing her
    "post Christmas" shopping. No "chores." ;-)

    Thanks.

    mp

    --
    Michael Powe org Naugatuck CT USA
    "When a person behaves in keeping with his conscience, when he
    tries to speak as a citizen even under conditions where
    citizenship is degraded, it may not lead to anything, yet it might.
    But what surely will not lead to anything is when a person calculates
    whether it will lead to something or not." -- Vaclav Havel, 1989
    Michael Guest

  10. #10

    Default Re: rescue damaged tar file

    Jean-David Beyer wrote: 
    > How do tape drives that do _hardware compression_ get around
    > this problem?
    >
    > I imagine they compress one block at a time. On my tape drives,
    > they have a 2 Megabyte buffer in the drive, and it normally
    > writes 65536-byte blocks to the tape. They employ a 4 layer Reed
    > Solomon error detection and correction scheme, and use what they
    > call Adaptive Lossless Data Compression (whatever that is). I am
    > also not sure what "4 layer Reed Solomon error detection and
    > correction" is. I know they do lateral and longitudinal and
    > diagonal parity checking of each block. Reed Solomon technique
    > is well known, but I do not know what the 4-layer is all about.
    >
    > http://www.siam.org/siamnews/mtc/mtc193.htm
    >
    > I always have hardware compression on (it is the default for the
    > drive), and have never lost anything. But that is 2 data points
    > (2 drives).[/ref]

    You might look into using ARJ for this sort of archival
    compression. It has provisions for generating the extra
    information needed to recover from faulty media. I don't know the
    algorithms used, nor have I really tested the result. It is free
    for personal use, but may not be available for Linux.

    <http://www.arjsoftware.com>

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    More details at: <http://cfaj.freeshell.org/google/>
    Chuck Guest

  11. #11

    Default Re: rescue damaged tar file

    Chuck F. wrote: 
    >> How do tape drives that do _hardware compression_ get around
    >> this problem?
    >>
    >> I imagine they compress one block at a time. On my tape drives,
    >> they have a 2 Megabyte buffer in the drive, and it normally
    >> writes 65536-byte blocks to the tape. They employ a 4 layer Reed
    >> Solomon error detection and correction scheme, and use what they
    >> call Adaptive Lossless Data Compression (whatever that is). I am
    >> also not sure what "4 layer Reed Solomon error detection and
    >> correction" is. I know they do lateral and longitudinal and
    >> diagonal parity checking of each block. Reed Solomon technique
    >> is well known, but I do not know what the 4-layer is all about.
    >>
    >> http://www.siam.org/siamnews/mtc/mtc193.htm
    >>
    >> I always have hardware compression on (it is the default for the
    >> drive), and have never lost anything. But that is 2 data points
    >> (2 drives).[/ref]
    >
    >
    > You might look into using ARJ for this sort of archival compression. It
    > has provisions for generating the extra information needed to recover
    > from faulty media. I don't know the algorithms used, nor have I really
    > tested the result. It is free for personal use, but may not be
    > available for Linux.
    >
    > <http://www.arjsoftware.com>
    >[/ref]
    I looked there, but they do not describe the algorithm used, so I cannot
    tell if it is superior to the hardware algorithm used in my tape drive itself.

    --
    .~. Jean-David Beyer Registered Linux User 85642.
    /V\ PGP-Key: 9A2FC99A Registered Machine 241939.
    /( )\ Shrewsbury, New Jersey http://counter.li.org
    ^^-^^ 08:55:00 up 30 days, 19:27, 5 users, load average: 4.12, 4.18, 4.13
    Jean-David Guest

  12. #12

    Default Re: rescue damaged tar file

    On 25 Dec 2005 22:19:22 -0500 Michael Powe <michael+org> wrote:
    |>>>>> "phil" == phil-news-nospam <net> writes:
    |
    | phil> [followup set to comp.unix.admin only]
    | phil> In comp.unix.admin Michael Powe <michael+org> wrote:
    |
    | phil> | I have a compressed archive that I created using GNU tar
    | phil> on a gentoo | system. The tar file is about 900 MB
    | phil> compressed and about 2.5 GB | uncompressed.
    | phil> |
    | phil> | This archive has bad data about 1/3 to 1/2 way through it.
    | phil> I'm trying | to find a way to get at the data below the
    | phil> damaged part. At the point | of failure, tar reports:
    |
    | phil> [etc]
    |
    | phil> Possibly the damage is in a form that effects the relative
    | phil> offset of the data, for example the addition or deletion of
    | phil> an amount of data that is not a multiple of 512 bytes. What
    | phil> a tar recovery program would have to do is look for what
    | phil> appears to be a valid tar header using every level of byte
    | phil> offset to find something. Assuming only one point of
    | phil> corruption, this might be doable from the end of the file
    | phil> working in reverse to the front. What is the exact number
    | phil> of bytes of the uncompressed copy?
    |
    | 1010083339 2005-12-24 15:44 powem12242005.tar.gz
    | 2469939203 2005-12-25 20:41 powem12242005.tar.recovered
    |
    | The "recovered" file is generated by gzrecover from GNU Recovery Tool Kit
    | (http://www.urbanophile.com/arenn/coding/gzrt/gzrt.html). Standard
    | gzip will not unpack the file and exits with a CRC error.
    |
    | BTW, if I had some pointers on yzing these tar files, I have some
    | knowledge of Java and perl and I'd be willing to spend some time
    | trying to "reverse engineer" the file, so to speak. I have no
    | experience handling binary files in that manner, though.

    If the damage was done to the compressed file, that could result in the
    uncompressed data being totally corrupt. The recovery tool would be a
    best effort attempt.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  13. #13

    Default Re: rescue damaged tar file

    Michael Powe wrote: 

    If the damage is in the tar phase not the compression phase, then
    playing around with:

    dd skip=N powem12242005.tar.recovered | tar tvf - | head

    might help. It's a huge "if" and it would take a lot of fshing to
    locate any header after the corrupt section. Especially not knowing
    in advance if it's the compression so there isn't any good point
    after the corruption.

    Doug Guest

  14. #14

    Default Re: rescue damaged tar file

    On 27 Dec 2005 07:57:20 -0800 Doug Freyburger <com> wrote:
    | Michael Powe wrote:
    |>
    |> phil> | This archive has bad data about 1/3 to 1/2 way through it.
    |> phil> I'm trying | to find a way to get at the data below the
    |> phil> damaged part. At the point | of failure, tar reports:
    |>
    |> 1010083339 2005-12-24 15:44 powem12242005.tar.gz
    |> 2469939203 2005-12-25 20:41 powem12242005.tar.recovered
    |
    | If the damage is in the tar phase not the compression phase, then
    | playing around with:
    |
    | dd skip=N powem12242005.tar.recovered | tar tvf - | head
    |
    | might help. It's a huge "if" and it would take a lot of fshing to
    | locate any header after the corrupt section. Especially not knowing
    | in advance if it's the compression so there isn't any good point
    | after the corruption.

    The size of his recovered file, 2469939203 bytes, is: 4824100 * 512 + 3
    I think the first issue is to found whereabout that extra 3 bytes is.
    Then increment in 512 byte steps in alignment with the end of the file
    to see where a valid tar header might be found, in the GZ recovery was
    able to re-stablish decompression state correctly.

    --
    -----------------------------------------------------------------------------
    | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
    | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
    -----------------------------------------------------------------------------
    phil-news-nospam@ipal.net Guest

  15. #15

    Default Re: rescue damaged tar file

    In article <this.yahoo.co.uk>,
    Jules <this.yahoo.co.uk> wrote: 
    >
    >Best option is to make absolutely certain that you can't get the damaged
    >section of the data back - if the reason for the corruption is due to the
    >source media (tape or disk say) then there are sometimes options there to
    >recover bad data...
    >
    >And in the future, don't compress archives of anything critical, just
    >because of potential problems like this :([/ref]

    Note that bzip & bzip2 do block compression (that's what the 'b' is for),
    and bzip2recover lets you split a bzip2 file into those blocks so that you can
    recover data from any that are not corrupted.

    John
    --
    John DuBois com KC6QKZ/AE http://www.armory.com/~spcecdt/
    John Guest

  16. #16

    Default Re: rescue damaged tar file

    >>>>> "phil-news-nospam" == phil-news-nospam <net> writes:

    phil-news-nospam> On 27 Dec 2005 07:57:20 -0800 Doug Freyburger <com> wrote:
    phil-news-nospam> | Michael Powe wrote:
    phil-news-nospam> |> |> phil> | This archive has bad data about
    phil-news-nospam> 1/3 to 1/2 way through it. |> phil> I'm trying
    phil-news-nospam> | to find a way to get at the data below the |>
    phil-news-nospam> phil> damaged part. At the point | of failure,
    phil-news-nospam> tar reports: |> |> 1010083339 2005-12-24 15:44
    phil-news-nospam> powem12242005.tar.gz |> 2469939203 2005-12-25
    phil-news-nospam> 20:41 powem12242005.tar.recovered | | If the
    phil-news-nospam> damage is in the tar phase not the compression
    phil-news-nospam> phase, then | playing around with: | | dd skip=N
    phil-news-nospam> powem12242005.tar.recovered | tar tvf - | head |
    phil-news-nospam> | might help. It's a huge "if" and it would
    phil-news-nospam> take a lot of fshing to | locate any header
    phil-news-nospam> after the corrupt section. Especially not
    phil-news-nospam> knowing | in advance if it's the compression so
    phil-news-nospam> there isn't any good point | after the
    phil-news-nospam> corruption.

    phil-news-nospam> The size of his recovered file, 2469939203
    phil-news-nospam> bytes, is: 4824100 * 512 + 3 I think the first
    phil-news-nospam> issue is to found whereabout that extra 3 bytes
    phil-news-nospam> is. Then increment in 512 byte steps in
    phil-news-nospam> alignment with the end of the file to see where
    phil-news-nospam> a valid tar header might be found, in the GZ
    phil-news-nospam> recovery was able to re-stablish decompression
    phil-news-nospam> state correctly.

    How can I tell what a tar header looks like? Where can I find out?
    When I 'head -c 512' or 'tail -c 512' the file, I see a mixture of text from text
    files and binary data, but I don't see anything identifiable.

    (Linux 2.4.31~ellen) [powem] [ /home]
    520 $ --> !head
    head -c 512 powem12242005.tar.recovered
    powem/#org_b_ahome_acgaw_apublic__html_alayout.html#0000 600000175000001440000000000010343042116026673 0ustar powemusers00000000000000

    Thanks.

    mp

    --
    Michael Powe org Naugatuck CT USA

    "The secret to strong security: less reliance on secrets."
    -- Whitfield Diffie
    Michael Guest

  17. #17

    Default Re: rescue damaged tar file

    Michael Powe wrote: 

    man tar. Look in the see also section. man 4 tar
    man file. Look in the see also section. man magic, more /etc/magic.

    This is how UNIX doentation works. It takes a while to get
    comfortable with how the man pages work.
     

    Yup, straight out of the section 4 doc on it. It needs binary for
    format,
    text because what good is a filename that isn't text.

    Doug Guest

  18. #18

    Default Re: rescue damaged tar file

    In article <trollope.org>, 

    In the olden days, man 5 tar would get you an explanation of the tar header.
    This seems to be gone from anything touched by GNU.

    Maybe you can find some other flavor of Unix system to look at. Or read
    the source for GNU tar to get some clues.

    carl

    --
    carl lowenstein marine physical lab u.c. san diego
    edu
    Carl Guest

  19. #19

    Default Re: rescue damaged tar file

    In article <dp50r3$g5a$ucsd.edu>,
    Carl Lowenstein <ucsd.edu> wrote: [/ref]
     
     

    man 5 tar on a FreeBSD system will list the tar structures for
    four different tar implementations going back to the original tar,
    ustar [Unix standard tar], gnutar, and one for spare-headers.

    Bill
    --
    Bill Vermillion - bv wjv . com
    Bill Guest

  20. #20

    Default Re: rescue damaged tar file

    "Michael Powe" <michael+org> wrote in message
    news:org
     

    You will of course have verified that your filesystem is capable of sizes >
    2 GB?
     
    .... 

    You might try modifying the code (e.g., s:/dev/rfd0:/your/tar/filename: )
    in
    http://paxutils.progiciels-bpi.ca/showfile.html?name=courriel/2-tape-salvaging&index=3 compile and run to see if that works around the corruption.

    ynotssor Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Damaged File
    By Darien_Graham-Smith@adobeforums.com in forum Adobe Indesign Windows
    Replies: 2
    Last Post: June 10th, 07:51 AM
  2. InDesign 2.0.2 damaged file... is it fixable or permanently damaged?
    By KathleenDarcy@adobeforums.com in forum Adobe Indesign Windows
    Replies: 3
    Last Post: June 4th, 05:09 PM
  3. File is Damaged
    By ann_roberti@adobeforums.com in forum Adobe Acrobat Windows
    Replies: 8
    Last Post: May 13th, 10:54 AM
  4. Rescue CD doesn't boot on Acer TM 800 after deleting rescue partition
    By Rene Lanz in forum Linux Setup, Configuration & Administration
    Replies: 2
    Last Post: July 8th, 02:27 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •