Erving
> I have an archive type ddc and it wont open, I just get an error message
> from Filer "Bad Archive" is there any chance of being able to access any
> of the contents? Other archives of the same type open OK with SparkFS.
What kind of archive is it? The fact that it's of type DDC doesn't mean
much -- what do the first few bytes of the file contain?
--
Steve Fryatt - Leeds, England
> On 20 Dec, Erving wrote in message
> <1c6babcc5...@orpheusnet.co.uk>:
>
> > I have an archive type ddc and it wont open, I just get an error message
> > from Filer "Bad Archive" is there any chance of being able to access any
> > of the contents? Other archives of the same type open OK with SparkFS.
>
> What kind of archive is it? The fact that it's of type DDC doesn't mean
> much -- what do the first few bytes of the file contain?
>
it starts:
Address : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII data
00000000: 50 4B 03 04 14 00 00 00 00 00 D2 60 43 30 00 00 : PK........�`C0..
00 00 00 00 00 00 00 00 00 00 0B 00 18 00 53 65 : ..............Se
00000020: 61 73 6F 6E 30 33 2E 34 2F 41 43 14 00 41 52 43 : ason03.4/AC..ARC
30 4C DC FD FF 33 32 ED 7A 33 00 00 00 00 00 00 : 0L���32�z3......
the files in it are mostly, maybe all, Artworks, I can spot some file names
but not recognize anything else.
--
Erving
The start of a zip file is marked by 'PK' (for Phil Katz) so it should be a
zip file. If you can't open it with the usual software that implies it's
corrupt.
--
David Holden - APDL - <http://www.apdl.co.uk>
I was hoping there might be some way of recovering some of it
--
Erving
> The start of a zip file is marked by 'PK' (for Phil Katz) so it should be a
> zip file. If you can't open it with the usual software that implies it's
> corrupt.
Unless it's one of the latest format zip files introduced by WinZip
12, which are more space-efficient, but not backwards compatible. I
don't know if they have a different identifier in the first few bytes
though. Of course, if the source of the file was from a RISC OS
machine this won't be the case.
--
Grahame Parish
Aylesbury, Bucks. HP19 (UK)
maillistDOTparishATmillersHYPHENwayDOTnet
> > The start of a zip file is marked by 'PK' (for Phil Katz) so it
> > should be a zip file. If you can't open it with the usual software
> > that implies it's corrupt.
> >
> I was hoping there might be some way of recovering some of it
There are some tools, such as the one in the Infozip suite. However,
Zip files store their directory of contents at the end, so if the file
has been truncated (the most common type of corruption) you're
essentially doomed.
Remember: compression should be used to speed transfer, not as a form
of storage!
B.
>
> Remember: compression should be used to speed transfer, not as a form
> of storage!
>
> B.
I'm not aware of ever seeing that advice given before. I'd better
decompress all my archived files once I find somewhere then to store
them! Does this also apply to !Squash?
--
Erving
> In message <20091221105...@trite.i.flarn.net.i.flarn.net>
> Rob Kendrick <nn...@rjek.com> wrote:
>
> >
> > Remember: compression should be used to speed transfer, not as a
> > form of storage!
>
> I'm not aware of ever seeing that advice given before. I'd better
> decompress all my archived files once I find somewhere then to store
> them! Does this also apply to !Squash?
The problem with compression is that the way it works is by /removing/
redundancy. Redundancy is a handy backup. Compression is useful for
saving money and speeding transfers. But should a single bit get
corrupted, it can be impossible to rebuild any of the data beyond that
broken one or zero.
As an example; imagine you have a photo. As a Sprite file, if a single
bit, or even a byte, is corrupt, you'll only damage one pixel (unless
the corruption happens somewhere very unfortunate.) If it were
compressed, it'd damage every pixel after it, corrupting most of the
image.
If you find yourself needing to compress data when archiving it, it
might be time to buy a larger hard disc instead.
B.
Where are they stored now? Put them there but uncompressed.
If they're compressed because you don't have enough storage,
get some more storage!
If they're on your main hard disc then you should really sort
out a proper backup solution unless you don't care about your
data.
> Does this also apply to !Squash?
Yes.
> >
> > Remember: compression should be used to speed transfer, not as a
> > form of storage!
> >
> I'm not aware of ever seeing that advice given before. I'd better
> decompress all my archived files once I find somewhere then to
> store them! Does this also apply to !Squash?
I once bought !CFS as a compressed way of storing files when my HD was
something like a vast-seeming 100 MB.
Then I read somewhere that !CFS was an unreliable form of storage -
but fortunately by then I'd obtained Zip-discs, onto which I could
archive them in uncompressed format.
Then I heard about the Zip-disc "click of death". By this time HDs had
come down in price and I could afford a couple of GBs.
Then I actually experienced the "click of death" of the HD . . I
hadn't heard that HDs can be short-lived.
Now I back it all up on VRPC. And also onto a superannuated VRPC. And
onto CDs just in case. 8-)
But like Erving, this is the first time I've read Rob Kendrick's
dictum.
Michael Harding
Rev. Preb. M.D. Harding ris...@mdharding.org.uk
zip -F or zip -FF will fix that too:
(This is on Linux, but the same tools exist for RISC OS too):
[Make a zipfile]
bash-3.1$ zip foo.zip *.tex
adding: ktikz-circuitikz-env.tex (deflated 61%)
adding: pazo2.tex (deflated 56%)
adding: pazo.tex (deflated 56%)
adding: pi.tex (deflated 48%)
adding: test.tex (deflated 22%)
bash-3.1$ joe foo.zip
[snip off the end in an editor]
File foo.zip saved
[Now try unzipping it]
bash-3.1$ unzip foo.zip
Archive: foo.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of foo.zip or
foo.zip.zip, and cannot find foo.zip.ZIP, period.
[Corrupted! Let's fix it]
bash-3.1$ zip -F foo.zip
zip: reading ktikz-circuitikz-env.tex
zip: reading pazo2.tex
zip warning: foo.zip would be truncated.
Retry with option -qF to truncate, with -FF to attempt full recovery
[So it found some files. Try to fix as much as we can]
bash-3.1$ zip -FF foo.zip
zip: reading ktikz-circuitikz-env.tex
zip: reading pazo2.tex
compressed size 184, actual size 66 for pazo2.tex
zip warning: foo.zip has been truncated.
[Did it work?]
bash-3.1$ unzip foo.zip
Archive: foo.zip
inflating: ktikz-circuitikz-env.tex
inflating: pazo2.tex
error: invalid compressed data to inflate
We recover all the files up to the break.
Theo
> In article <4c9f1ccd5...@orpheusnet.co.uk>,
> Erving <erv...@riscos.org> wrote:
> > In message <20091221105...@trite.i.flarn.net.i.flarn.net>
> > Rob Kendrick <nn...@rjek.com> wrote:
> > >
> > > Remember: compression should be used to speed transfer, not as a form
> > > of storage!
>
> > I'm not aware of ever seeing that advice given before. I'd better
> > decompress all my archived files once I find somewhere then to store
> > them! Does this also apply to !Squash?
[snip tales of near data loss]
If the data matters, you'll keep multiple copies. If the files are
important to you, just stop and consider what would happen if the disc
failed in the next minute -- what would you have lost thet you couldn't
replace?
And when you start to think in these terms, you find you have much more
'important' data that you first thought.
> But like Erving, this is the first time I've read Rob Kendrick's dictum.
I've not seen Rob's exact expression of it before, but the basic sentiment
has been wise advice for many years. A single corruption can cause the
complete loss of a compressed archive, whereas it may only lose a single
file or even part of a single file when stored uncompressed.
Another good RISC OS example is MsgServe (and possibly NewsBase and Pluto)
having the option to compress mails in the database. While using the
compression may save a few quid now, leaving it off and buying a bigger disc
is a better option (as anyone who has suffered a disc error with a
compressed NewsDir will be able to confirm).
Good point. On a related theme:
Someone at the last RISC OS show told me his maxim about saving data.
"If you think to yourself I'll just do X and then save this file, don't,
save it first" You'll kick yourself if you don't!
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!