Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #1671 > unrolled thread

How reliable is zipping in Windows 7 Explorer?

Back to article view | Back to comp.compression

Contents

  How reliable is zipping in Windows 7 Explorer? AndyHancock <andymhancock@gmail.com> - 2013-01-06 13:51 -0800
    Re: How reliable is zipping in Windows 7 Explorer? Char Jackson <none@none.invalid> - 2013-01-06 17:25 -0600
      Re: How reliable is zipping in Windows 7 Explorer? Carson Chittom <carson@wistly.net> - 2013-01-06 17:41 -0600
        Re: How reliable is zipping in Windows 7 Explorer? Char Jackson <none@none.invalid> - 2013-01-06 23:39 -0600
          Re: How reliable is zipping in Windows 7 Explorer? andymhancock@gmail.com - 2013-01-11 22:46 -0800
            Re: How reliable is zipping in Windows 7 Explorer? Robert Wessel <robertwessel2@yahoo.com> - 2013-01-12 03:33 -0600
              Re: How reliable is zipping in Windows 7 Explorer? andymhancock@gmail.com - 2013-01-19 23:29 -0800
                Re: How reliable is zipping in Windows 7 Explorer? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-20 08:10 +0000
                  Re: How reliable is zipping in Windows 7 Explorer? Willem <willem@turtle.stack.nl> - 2013-01-20 11:33 +0000
                    Re: How reliable is zipping in Windows 7 Explorer? franklin.macintosh@gmail.com - 2013-01-25 22:23 -0800
    Re: How reliable is zipping in Windows 7 Explorer? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-01-06 23:57 +0000
      Re: How reliable is zipping in Windows 7 Explorer? BGB <cr88192@hotmail.com> - 2013-01-07 01:24 -0600
        Re: How reliable is zipping in Windows 7 Explorer? andymhancock@gmail.com - 2013-01-11 23:04 -0800

#1671 — How reliable is zipping in Windows 7 Explorer?

There have been times in the past when a zip file I created was
corrupt (or became corrupt somehow).  I encountered this either using
WinZip or command-line zip, possibly in old Unix environments.  To me,
there is a risk in relying solely on zip archives and deleting the
original unzipped files.  The risk isn't only in losing one file that
is corrupt -- any corruption anywhere in the entire archive could
render all the files therein inaccessible.  Hence, the risk increases
with the size of the archive.

How reliable is the zip that is native to Windows 7?  In addition to
that general question, what about specifically for files in the
Gigabyte range (fraction of a GB or several GBs)?  If it is very
reliable, then I will use the Windows 7's "compressed (zipped) folder"
to create archives for writing to DVD.

I am using Windows 7 Professional 64-bit.  I want to avoid discussion
about Windows 7 backup as it is not suitable for my specific purposes.

[toc] | [next] | [standalone]

#1672

On Sun, 6 Jan 2013 13:51:53 -0800 (PST), AndyHancock
<andymhancock@gmail.com> wrote:

>There have been times in the past when a zip file I created was
>corrupt (or became corrupt somehow).  I encountered this either using
>WinZip or command-line zip, possibly in old Unix environments.  To me,
>there is a risk in relying solely on zip archives and deleting the
>original unzipped files.  The risk isn't only in losing one file that
>is corrupt -- any corruption anywhere in the entire archive could
>render all the files therein inaccessible.  Hence, the risk increases
>with the size of the archive.

If you're concerned with the integrity of any data files, zip or otherwise,
one way to get peace of mind is to use Quickpar to create a recovery set.
Normally, 10% is a nice round number to use, but feel free to adjust the
settings as you see fit. With a Quickpar recovery set, not only can you know
for sure whether your data is intact, but if it's damaged you can repair it.

<http://www.quickpar.org.uk/>

>How reliable is the zip that is native to Windows 7?

It's fine, as far as it goes. The zip spec has been around for a long time
and is well known, but it's subject to corruption from outside factors.
Tools like Quickpar address those weaknesses, whether for zip files or any
other type of digital file.

[toc] | [prev] | [next] | [standalone]

#1673

Char Jackson <none@none.invalid> writes:

> On Sun, 6 Jan 2013 13:51:53 -0800 (PST), AndyHancock
> <andymhancock@gmail.com> wrote:
>
>>There have been times in the past when a zip file I created was
>>corrupt (or became corrupt somehow).  I encountered this either using
>>WinZip or command-line zip, possibly in old Unix environments.  To me,
>>there is a risk in relying solely on zip archives and deleting the
>>original unzipped files.  The risk isn't only in losing one file that
>>is corrupt -- any corruption anywhere in the entire archive could
>>render all the files therein inaccessible.  Hence, the risk increases
>>with the size of the archive.
>
> If you're concerned with the integrity of any data files, zip or otherwise,
> one way to get peace of mind is to use Quickpar to create a recovery set.
> Normally, 10% is a nice round number to use, but feel free to adjust the
> settings as you see fit. With a Quickpar recovery set, not only can you know
> for sure whether your data is intact, but if it's damaged you can repair it.
>
> <http://www.quickpar.org.uk/>
>
>>How reliable is the zip that is native to Windows 7?
>
> It's fine, as far as it goes. The zip spec has been around for a long time
> and is well known, but it's subject to corruption from outside factors.
> Tools like Quickpar address those weaknesses, whether for zip files or any
> other type of digital file.

In my experience the disk is more likely to be a problem than the
file--particularly optical disks.  It's also worth mentioning the
obvious that for anything you really care about, you should back it up
in more than one place--and every so often, you should actually try to
restore--in a non-emergency way--from the backups you have, to make sure
they really are backups and not random bits.

[toc] | [prev] | [next] | [standalone]

#1676

On Sun, 06 Jan 2013 17:41:24 -0600, Carson Chittom <carson@wistly.net>
wrote:

>Char Jackson <none@none.invalid> writes:
>
>> On Sun, 6 Jan 2013 13:51:53 -0800 (PST), AndyHancock
>> <andymhancock@gmail.com> wrote:
>>
>>>There have been times in the past when a zip file I created was
>>>corrupt (or became corrupt somehow).  I encountered this either using
>>>WinZip or command-line zip, possibly in old Unix environments.  To me,
>>>there is a risk in relying solely on zip archives and deleting the
>>>original unzipped files.  The risk isn't only in losing one file that
>>>is corrupt -- any corruption anywhere in the entire archive could
>>>render all the files therein inaccessible.  Hence, the risk increases
>>>with the size of the archive.
>>
>> If you're concerned with the integrity of any data files, zip or otherwise,
>> one way to get peace of mind is to use Quickpar to create a recovery set.
>> Normally, 10% is a nice round number to use, but feel free to adjust the
>> settings as you see fit. With a Quickpar recovery set, not only can you know
>> for sure whether your data is intact, but if it's damaged you can repair it.
>>
>> <http://www.quickpar.org.uk/>
>>
>>>How reliable is the zip that is native to Windows 7?
>>
>> It's fine, as far as it goes. The zip spec has been around for a long time
>> and is well known, but it's subject to corruption from outside factors.
>> Tools like Quickpar address those weaknesses, whether for zip files or any
>> other type of digital file.
>
>In my experience the disk is more likely to be a problem than the
>file--particularly optical disks.

Optical disc issues are included in what I said above. If the optical disc
develops a problem, it's still the files that are affected. Tools like
Quickpar will let you know whether the files are ok, and if not, whether
they can be repaired.

>It's also worth mentioning the
>obvious that for anything you really care about, you should back it up
>in more than one place--and every so often, you should actually try to
>restore--in a non-emergency way--from the backups you have, to make sure
>they really are backups and not random bits.

If you use a tool like Quickpar, (I feel like I'm preaching by now, but it's
the most widely used and therefore the best example), you don't have to
actually unzip anything. You can just run an integrity check and be done
with it.

[toc] | [prev] | [next] | [standalone]

#1688

On Monday, January 7, 2013 12:39:47 AM UTC-5, Char Jackson wrote:
>On Sun, 06 Jan 2013 17:41:24 -0600, Carson Chittom
><carson@wistlyDOTnet> wrote:
>>Char Jackson <none@noneDOTinvalid> writes:
>>>On Sun, 6 Jan 2013 13:51:53 -0800 (PST), AndyHancock wrote:
>>>> How reliable is the zip that is native to Windows 7?
>>>
>>> It's fine, as far as it goes. The zip spec has been around for a
>>> long time and is well known, but it's subject to corruption from
>>> outside factors.  Tools like Quickpar address those weaknesses,
>>> whether for zip files or any other type of digital file.
>>
>> In my experience the disk is more likely to be a problem than the
>> file--particularly optical disks.
>
> Optical disc issues are included in what I said above. If the
> optical disc develops a problem, it's still the files that are
> affected. Tools like Quickpar will let you know whether the files
> are ok, and if not, whether they can be repaired.
>
>> It's also worth mentioning the obvious that for anything you really
>> care about, you should back it up in more than one place--and every
>> so often, you should actually try to restore--in a non-emergency
>> way--from the backups you have, to make sure they really are
>> backups and not random bits.
>
> If you use a tool like Quickpar, (I feel like I'm preaching by now,
> but it's the most widely used and therefore the best example), you
> don't have to actually unzip anything. You can just run an integrity
> check and be done with it.

Thanks, Carson, Char.  Quickpar looks very interesting.

About replicating my backups, I don't really have more than one abode to keep two geographically separate items.  A fire will wipe out everything :( .

Point well taken about testing the backup, and how easy Quickpar makes it.  Tar+gzip allows an actual comparison with the unarchived source files, and zip also has a command line switch for integrity checking.

[toc] | [prev] | [next] | [standalone]

#1690

On Fri, 11 Jan 2013 22:46:45 -0800 (PST), andymhancock@gmail.com
wrote:

>On Monday, January 7, 2013 12:39:47 AM UTC-5, Char Jackson wrote:
>>On Sun, 06 Jan 2013 17:41:24 -0600, Carson Chittom
>><carson@wistlyDOTnet> wrote:

>>> It's also worth mentioning the obvious that for anything you really
>>> care about, you should back it up in more than one place--and every
>>> so often, you should actually try to restore--in a non-emergency
>>> way--from the backups you have, to make sure they really are
>>> backups and not random bits.
>>
(...)
>
>About replicating my backups, I don't really have more than one abode to keep two geographically separate items.  A fire will wipe out everything :( .


Banks rent safe-deposit boxes for fairly reasonable rates.

[toc] | [prev] | [next] | [standalone]

#1698

On Saturday, January 12, 2013 4:33:08 AM UTC-5, robert...@yahoo.com
wrote:
>On Fri, 11 Jan 2013 22:46:45 -0800 (PST), andymhancockATgmail.com
>wrote:
>> About replicating my backups, I don't really have more than one
>> abode to keep two geographically separate items.  A fire will wipe
>> out everything :( .
>
> Banks rent safe-deposit boxes for fairly reasonable rates.

They're quite small!

But seriously, who replicates home backups and stores them at different locations?  I know that one has to do it for serious backup, but who has found this feasible enough to do regularly?

[toc] | [prev] | [next] | [standalone]

#1699

andymhancock@gmail.com wrote:

(snip, someone wrote)

>> Banks rent safe-deposit boxes for fairly reasonable rates.
 
> They're quite small!
 
> But seriously, who replicates home backups and stores them 
> at different locations?  I know that one has to do it for 
> serious backup, but who has found this feasible enough to 
> do regularly?

My bank has the smallest box free for customers with the 
appropriate account. I put some CD-Rs in with some files
that I would like to keep. (Mostly JPGs from digital cameras.

But yes, I haven't been very good at regularly bringing in
newer copies. Still, better than nothing.

-- glen

[toc] | [prev] | [next] | [standalone]

#1700

glen herrmannsfeldt wrote:
) andymhancock@gmail.com wrote:
)
) (snip, someone wrote)
)
)>> Banks rent safe-deposit boxes for fairly reasonable rates.
)  
)> They're quite small!
)  
)> But seriously, who replicates home backups and stores them 
)> at different locations?  I know that one has to do it for 
)> serious backup, but who has found this feasible enough to 
)> do regularly?
)
) My bank has the smallest box free for customers with the 
) appropriate account. I put some CD-Rs in with some files
) that I would like to keep. (Mostly JPGs from digital cameras.
)
) But yes, I haven't been very good at regularly bringing in
) newer copies. Still, better than nothing.

There are several distributed, P2P, backup system where you and a couple of
friends all share disk space to keep backups for each other, over the
internet.  Encrypted, of course.

I haven't looked at any yet but I assume you can set it up to do nightly
incremental backups.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#1727

On Sunday, January 20, 2013 6:33:34 AM UTC-5, Willem wrote:
> There are several distributed, P2P, backup system where you and a
> couple of friends all share disk space to keep backups for each
> other, over the internet.  Encrypted, of course.
> 
> I haven't looked at any yet but I assume you can set it up to do
> nightly incremental backups.

Interesting idea.  But I think I'll try to stay with personal backups.
Thanks.

[toc] | [prev] | [next] | [standalone]

#1674

In comp.compression AndyHancock <andymhancock@gmail.com> wrote:

> There have been times in the past when a zip file I created was
> corrupt (or became corrupt somehow).  I encountered this either using
> WinZip or command-line zip, possibly in old Unix environments.  To me,
> there is a risk in relying solely on zip archives and deleting the
> original unzipped files.  The risk isn't only in losing one file that
> is corrupt -- any corruption anywhere in the entire archive could
> render all the files therein inaccessible.  Hence, the risk increases
> with the size of the archive.

For tgz, the usual unix gzipped tar file, any corruption makes it
pretty hard to recover anything after that.

As I understand zip, though, each file is compressed separately.
The index is at the end, and could be lost or corrupt, but it is usually
possible to find the beginning of a file, and uncompress it, even
without the index.
 
> How reliable is the zip that is native to Windows 7?  In addition to
> that general question, what about specifically for files in the
> Gigabyte range (fraction of a GB or several GBs)?  If it is very
> reliable, then I will use the Windows 7's "compressed (zipped) folder"
> to create archives for writing to DVD.

You mean how often does it create corrupt zip files?

I would expect more often the corruption occurs later.

You could store them on a RAID (redundant) disk to reduce the corruption
that could happen.

-- glen

[toc] | [prev] | [next] | [standalone]

#1675

On 1/6/2013 5:57 PM, glen herrmannsfeldt wrote:
> In comp.compression AndyHancock <andymhancock@gmail.com> wrote:
>
>> There have been times in the past when a zip file I created was
>> corrupt (or became corrupt somehow).  I encountered this either using
>> WinZip or command-line zip, possibly in old Unix environments.  To me,
>> there is a risk in relying solely on zip archives and deleting the
>> original unzipped files.  The risk isn't only in losing one file that
>> is corrupt -- any corruption anywhere in the entire archive could
>> render all the files therein inaccessible.  Hence, the risk increases
>> with the size of the archive.
>
> For tgz, the usual unix gzipped tar file, any corruption makes it
> pretty hard to recover anything after that.
>
> As I understand zip, though, each file is compressed separately.
> The index is at the end, and could be lost or corrupt, but it is usually
> possible to find the beginning of a file, and uncompress it, even
> without the index.
>

it is also (often) possible to recover files from chunks of multi-part 
ZIP archives, if the person knows how to do so...

there is a problem though that some tools are stupid and will make no 
attempt to access an archive if they can't find the "end of central 
directory" marker, but this is more of a problem of stupid tools than 
the ZIP format itself.


this is partly because the ZIP format compresses each file separately, 
and actually stores information about each file in several locations:
directly preceding the compressed file data;
in the central directory (stored at the end of the archive).

more so, each entry also has a nifty magic-code which can be used for 
resynchronization.


note though that one thing which may often irreparably foul up ZIP 
archives is LF <-> CR-LF autoconversion, which can happen sometimes. 
this was often as a result of buggy FTP software (which mistakenly 
identified a binary file as text), or occasionally brain-damaged 
filesystem code (such as cases of UMSDOS auto-conversion being enabled).

(possibly as a result) some formats (such as PNG) include special logic 
to at least detect if the file has gotten screwed up by such a conversion.


>> How reliable is the zip that is native to Windows 7?  In addition to
>> that general question, what about specifically for files in the
>> Gigabyte range (fraction of a GB or several GBs)?  If it is very
>> reliable, then I will use the Windows 7's "compressed (zipped) folder"
>> to create archives for writing to DVD.
>
> You mean how often does it create corrupt zip files?
>
> I would expect more often the corruption occurs later.
>
> You could store them on a RAID (redundant) disk to reduce the corruption
> that could happen.
>

yep.

although, ironically, while raid protects fairly well against physical 
failure of disks, it (sadly) generally lacks any protection against 
OS-induced corruption (such as cases where the OS kernel gets corrupt 
somehow and manages to go berserk somewhat before finally crashing / 
blue-screening...).

often following these events, files would often be "sliced and diced", 
often with contents of one file being mixed in with another, ...


this partly gave me a mistrust of NTFS on WinXP computers, partly as 
IME, NTFS drives seemed to get fouled up by crashes a lot more often 
than FAT32 drives.

luckily, this issue seems to have largely gone away AFAICT in Vista and 
Win7.


for external archiving, it is a tradeoff...
I have often found the long-term reliability of CD-R and DVD-R's to 
sometimes be a bit lacking...

granted, even as such, they still seem to hold up better IME than old 
HDDs. if an HDD is left sitting unused for a number of years, often 
either the spindle is stuck (so it can't spin up) or the contents are 
otherwise corrupt/unreadable.

OTOH, IME, HDDs seem to last a lot longer when used occasionally, as 
this seems to keep the spindles from seizing, and causes data to 
regenerate (I suspect because HDDs will read and rewrite sectors to help 
keep their contents from degrading and similar).


usually, at least some contents can be recovered from an old CD-R, but 
not a whole lot can be recovered from a seized HDD...


or such...

[toc] | [prev] | [next] | [standalone]

#1689

On Monday, January 7, 2013 2:24:41 AM UTC-5, BGB wrote:
>On 1/6/2013 5:57 PM, glen herrmannsfeldt wrote:
>>In comp.compression AndyHancock <andymhancock@gmailDOTcom> wrote:
>>> There have been times in the past when a zip file I created was
>>> corrupt (or became corrupt somehow).  I encountered this either
>>> using WinZip or command-line zip, possibly in old Unix
>>> environments.  To me, there is a risk in relying solely on zip
>>> archives and deleting the original unzipped files.  The risk isn't
>>> only in losing one file that is corrupt -- any corruption anywhere
>>> in the entire archive could render all the files therein
>>> inaccessible.  Hence, the risk increases with the size of the
>>> archive.
>>
>> For tgz, the usual unix gzipped tar file, any corruption makes it
>> pretty hard to recover anything after that.
>>
>> As I understand zip, though, each file is compressed separately.
>> The index is at the end, and could be lost or corrupt, but it is
>> usually possible to find the beginning of a file, and uncompress
>> it, even without the index.
>
> it is also (often) possible to recover files from chunks of
> multi-part ZIP archives, if the person knows how to do so...  there
> is a problem though that some tools are stupid and will make no
> attempt to access an archive if they can't find the "end of central
> directory" marker, but this is more of a problem of stupid tools
> than the ZIP format itself.  this is partly because the ZIP format
> compresses each file separately, and actually stores information
> about each file in several locations: directly preceding the
> compressed file data; in the central directory (stored at the end of
> the archive).  more so, each entry also has a nifty magic-code which
> can be used for resynchronization.  note though that one thing which
> may often irreparably foul up ZIP archives is LF <-> CR-LF
> autoconversion, which can happen sometimes.  this was often as a
> result of buggy FTP software (which mistakenly identified a binary
> file as text), or occasionally brain-damaged filesystem code (such
> as cases of UMSDOS auto-conversion being enabled).  (possibly as a
> result) some formats (such as PNG) include special logic to at least
> detect if the file has gotten screwed up by such a conversion.

I want to avoid the need to dissect archives in recover what can be recovered.

>>> How reliable is the zip that is native to Windows 7?  In addition
>>> to that general question, what about specifically for files in the
>>> Gigabyte range (fraction of a GB or several GBs)?  If it is very
>>> reliable, then I will use the Windows 7's "compressed (zipped)
>>> folder" to create archives for writing to DVD.
>>
>> You mean how often does it create corrupt zip files?  I would
>> expect more often the corruption occurs later.  You could store
>> them on a RAID (redundant) disk to reduce the corruption that could
>> happen.
>
> yep.
>
> although, ironically, while raid protects fairly well against
> physical failure of disks, it (sadly) generally lacks any protection
> against OS-induced corruption (such as cases where the OS kernel
> gets corrupt somehow and manages to go berserk somewhat before
> finally crashing / blue-screening...).
>
> often following these events, files would often be "sliced and
> diced", often with contents of one file being mixed in with another,
> ...  this partly gave me a mistrust of NTFS on WinXP computers,
> partly as IME, NTFS drives seemed to get fouled up by crashes a lot
> more often than FAT32 drives.
>
> luckily, this issue seems to have largely gone away AFAICT in Vista
> and Win7.
>
> for external archiving, it is a tradeoff...  I have often found the
> long-term reliability of CD-R and DVD-R's to sometimes be a bit
> lacking...
>
> granted, even as such, they still seem to hold up better IME than
> old HDDs. if an HDD is left sitting unused for a number of years,
> often either the spindle is stuck (so it can't spin up) or the
> contents are otherwise corrupt/unreadable.

I want to back up different snapshots in time onto separate passive discs rather than collecting snapshots onto one HDD (RAID or otherwise).

> OTOH, IME, HDDs seem to last a lot longer when used occasionally, as
> this seems to keep the spindles from seizing, and causes data to
> regenerate (I suspect because HDDs will read and rewrite sectors to
> help keep their contents from degrading and similar).
>
> usually, at least some contents can be recovered from an old CD-R,
> but not a whole lot can be recovered from a seized HDD...

The reason why I am more comfortable with separate passive media despite the question of data longevity has more to do with your previous comment about the complexity of an HD, with more things that can break down.  If I take regular snapshots onto disc, I probably won't lose both of the 2 most recent snapshots at the same time.  However, I admit that it isn't clear to me whether RAID or discs is better overall.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web