I recently discovered another reason not to delete in camera. Doing so
may prevent complete recovery of all images in the event the card is
accidentally formatted and you need to use a recovery utility.
A few weeks ago I shot an event in the morning which was scheduled to
continue in the evening. In the morning there had been extremely bright
sun and I was doing a lot of exposure testing and chimping with the 5D.
Since I wasn't under much time pressure then I was also editing out a
few of the outtakes as I got a chance.
Some four or five hours later I remembered that I intended to do some
tests on a flash unit, picked up the camera and (routinely** for me)
pressed the format button. I think my thumb was still on the button
when I realized the error of my ways. I was suffering cardiac arrest
for a few seconds before I realized that I should be able to recover the
images with a file recovery utility. But that was only partially true
because of my editing.
When you format a disk with DOS (and a CF card is a logical disk) the
only thing that happens is that the directory information is deleted.
All the file data is still there but the file names, dates and times,
and (most importantly) the size and storage locations of each file are
lost. But the DOS FAT16 and FAT32 file systems will allocate space
sequentially on a freshly formatted disk. Therefore, if you've taken 5
images and haven't deleted anything, the images are simply strung back
to back on the disk as 1, 2, 3, 4, 5. A recovery utility can figure
this out if it can recognize the header information of various file
types. Once it has found the header for images 1 and 2 it will assume
that everything in between is part of image 1.
If you now take image 6 it will be strung along right after 5 *unless*
you've done some editing and deleted image 3. Depending on the DOS
implementation, it might choose to place image 6 right after image 5 or,
recognizing that there's a hole where image 3 used to be, it may decide
to put image 6 in that empty space. All is still well if image 6 is
able to fit in the hole but, if not, part of image 6 will fill up the
hole and the remainder will be placed after image 5. At this point
image 6 is no longer completely recoverable because the recovery utility
has no way of knowing that it's missing its tail and, even if it did,
has no way of knowing where the tail is. Depending on how smart the
recovery utility is it may also end up corrupting image 5 by considering
the tail end of number 6 as the tail end of number 5. But the image
processing software such as raw converters or PhotoShop may be able to
recover from that *if* the structure of the image file allows them to
ignore the extraneous bits of image 6 tacked on the end of image 5.
The first few versions of DOS always allocated space so as to
immediately reuse the holes created by deleted files. By about version
2 or 3 we changed the allocation strategy to first use all the
previously unallocated space at the end and only come back to fill in
the holes if it was necessary. That was done specifically to allow for
maximizing file system performance and also maximizing the amount of
date recovered if a disk was accidentally formatted.
I was quite surprised to discover that the 5D is using the original DOS
allocation strategy of filling in the holes first. It was obvious
because some images were corrupted and not recoverable and what was
recovered wasn't necessarily in the sequence the images were shot.
Fortunately, there was a lot of redundancy in the images and, all things
considered, I didn't lose anything of critical importance.
In thinking about it since then it occurs to me that the DOS
implementation for the 5D may have changed the file system allocation
logic back to the original (use the holes first) because it was no
longer considered necessary for performance. On a mechanical disk
fastest reading and writing goes to sequential allocation. If the data
is spread around in multiple holes the read/write head may have to do a
lot of hopping around from one cylinder/track to another. This causes
time loss in moving the head and also rotational delays in waiting for
the right data to come around to the head's location. For a solid state
device such as a CF card there are no head movement delays. Depending
on the technology, there may be something analogous to rotational delays
but these are probably so short that they are immaterial.
Anyhow, if that was the thinking, they forgot about the data recovery
part of the equation. I guess the institutional memory of 20+ years ago
has faded.
Anyhow, if you have a Canyon 5D (and probably many other brands/models
as well) don't do editing in the field unless you have to.
** So, how did I end up in this situation in the first place. Failure
to follow normal routine. Normally, upon return from a shoot, the CF
card is immediately backed up to a hard drive and the CF card is removed
and not to be reused until the hard drive has been backed up. The rule
is supposed to be that the CF card is not to be reused until there are
two backup copies. In this case I failed to back up the card and also
failed to replace it with another one with older content. Also, when I
picked up the camera I inexplicably formatted the CF card without first
checking it for image content. The actions of my fingers were 5
milliseconds ahead of my thought process.
Chuck Norcutt
Moose wrote:
>
> I've never run into any problems doing this, although, as I said, I
> avoid it on principle whenever possible. I have the impression that the
> EOS file system is pretty robust and forgiving. On the other hand, I've
> never had to do deleting other than the last shot on the F10 or F30, and
> I would be hesitant to do so. The Fuji xD file system seems to be less
> fragile than the Oly version, but I don't trust it to deal reliably with
> anything tricky. Overcaution? Oh well. With space for about 340 of its
> highest rez shots on the 1gb card, I haven't come close to needing to
> delete in camera but for the odd last shot that I know is junk.
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|