home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!uknet!cam-cl!doc.ic.ac.uk!doc.ic.ac.uk!iwm
- From: iwm@doc.ic.ac.uk (Ian W Moor)
- Newsgroups: comp.sys.amiga.hardware
- Subject: Re: Ways to double hard drive capacity???
- Message-ID: <191l97INN2v6@frigate.doc.ic.ac.uk>
- Date: 14 Sep 92 09:16:23 GMT
- References: <oleg.031b@crumpet.cts.com> <2ywn+sn.fuzzy@netcom.com> <18uvp8INNoal@agate.berkeley.edu>
- Reply-To: iwm@doc.ic.ac.uk (Ian W Moor)
- Organization: Department Of Computing, Imperial College, London UK
- Lines: 25
- NNTP-Posting-Host: swan.doc.ic.ac.uk
-
-
- In article <18uvp8INNoal@agate.berkeley.edu>, kevinm@ocf.berkeley.edu
- (Kevin Miller) writes:
- |> This is no flame, but a serious question. How does stacker handle the
- |> possibility of system crashes during the time that it takes to
- compress a file?
- |> With multi-tasking systems, it seems entirely possible that at some
- point the
- |> system will crash while the on-the-fly compression program is still
- compressing
- |> a file (especially if the compressed file is large).
- |>
- What worries me more is that by compressing a file, you lose all redundancy,
- if one byte of a compressed file is changed, all the rest of the file has
- potentially been lost, at the very least garbled. I've had this happen on
- a network transfer of a compressed file. So one of your programs writes
- a byte in the wrong place and then crashes your machine, when you reboot a
- file you wrote weeks back is garbled.
-
- Ian W. Moor
-
- iwm@doc.ic.ac.uk Department of Computing, Imperial College.
- 180 Queensgate London SW7 UK.
- "Experts from BNFL have advised the Russians to rename Chernobyl as Sellograd
- and open a tourist centre"
-