According to the wikato linux uners group:
http://www.wlug.org.nz/FileAllocationTable
Insufficient redundancy
A FAT is unreliable. A single bit error may lead to inconsistencies with
several files - they may become crosslinked, with one of the chains pointing
to cluster in the other chain. Since allocation of disk space happens in the
same step as assigning it to a file, a crash can easily lead to unduly or
incompletely allocated space. A crash during rewriting or deleting a file
can lead to the a part of the existing chain persisting, without any file
pointing to it, thus leaving it inaccessible. Microsoft tried to mitigate
these problems by storing a backup version of the table on the partition,
but only managed to exacerbate the problem by requiring a fragile procedure
to succeed multiple times. In addition, there is no indication of which copy
is authoritative, when they differ.
FAT uses a FirstFit method to allocate DiskClusters to files. According to
the "MS-DOS Operating System Programmer's Reference Manual" (for DOS 2.0),
"this permits the most efficient utilization[sic? of disk space because
clusters made available by erasing files can be allocated for new files."
Unfortunately, this also causes severe file fragmentation. To combat
fragmentation, defragmentation programs were written - first by third party
vendors, but later also by Microsoft Corporation themselves. These move
DiskClusters around so that all files end up in one piece , one after the
other, at the beginning of the disk. Unfortunately, FirstFit strategy means
that any grown file's new clusters will now end up behind the mass of
allocated ones, causing fragmentation to affect performance even more
gravely.
I tend to see far more information on FAT and file structures on LUGs (Linux
User Groups) than anywhere else (even more so than in the various MS
programmer reference manuals).
Allan
PS No trees were harmed in the sending of this message and a very large
number of electrons were asked their permission to be terribly
inconvenienced. (And threw a party for them afterwards for being really cool
about it).
Disrupting the unnatural balance that you, as a conscious human being and a
confused mass of energy, have created.
-Disturb the mind -
>From: Chuck Norcutt <chucknorcutt@xxxxxxxxxxxxxxxx>
>Reply-To: olympus@xxxxxxxxxx
>To: olympus@xxxxxxxxxx
>Subject: [OM] Re: Deleting in the Camera
>Date: Tue, 16 Jan 2007 07:58:44 -0500
>
>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
>==============================================
_________________________________________________________________
MSN Hotmail is evolving ? check out the new Windows Live Mail
http://ideas.live.com
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|