You might the following PDF on Loop back devices, cards and images useful.
http://www.devtarget.org/downloads/ca616-seufert-wolfgarten-lab3-report.pdf
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: "Allan Mee" <bigalsgroups@xxxxxxxxxxx>
>Reply-To: olympus@xxxxxxxxxx
>To: olympus@xxxxxxxxxx
>Subject: [OM] Re: Deleting in the Camera
>Date: Tue, 16 Jan 2007 16:08:00 +0000
>
>
>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
>==============================================
_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters!
http://www.msn.co.uk/newsletters
==============================================
List usage info: http://www.zuikoholic.com
List nannies: olympusadmin@xxxxxxxxxx
==============================================
|