On Mon, 10 May 2004 08:57:05 +0100, "David W.E. Roberts"
wrote:


"Rick Dipper" wrote in message
.. .
snip
In my experience most of these systems hold the index in memory, and
the data on the disk. Only at intervals do they flush the index
changes onto the disk. As each file is very rarely held in one
contigious lump, you need the index to find all the bits and put them
back together in the right order.

** However they do have to flush any memory buffers before the card is
removed - this should happen each time you power off the camera, at a
minimum. If not, how can you read the card in an external reader? **

Also I have found most of these system have multiple indexes, so that
various activites can be undertaken at speed. The "fixer" programs use
the multiple indexes to try and reserect the files.

A directory, is only a special type of file, it is not the index.

** A while since I looked at this, but doesn't a directory/folder hold the
details of the file name, attributes, and a pointer to the linked list (or
chain or similar) of individual blocks which makes up the body of the file?
AFAICS the camera is using FAT as the format to store data to aid
compatability with PCs when copying pictures. Granted there may be hidden
files which hold 'non-FAT' fast access data, or possibly another partition
on the disc for the camera-specific data, however the FAT partition seems to
be well thrashed. Difficult to draw a comparison with a real disc as there
are no moving parts and therefore there must be something there which
provides a virtual mapping from direct memory address to to head and
cylinder. Quite possibly this is damaged. **

In the good old days, you had cylinders heads sectors etc, and you
cound precisely control where data ended up on the disk. Nowdays a
disk is just hugle long streem of sectors, and the disk controller
fales up the cylinders/heads sectors counts. You can alter these
figures to a very large degree, and the things still work.


I would start by reading the device in "raw" (charcater) mode. If you
can read all the 16M they the device itself is not damaged, only the
indexes. If this fails, then the device is most likley damaged. Once
you have read the device, you can sit with the filesystems source
code, and binary dumps of your device and piece it all back together
again. This ls a long boring exercise not to be recommended to anyone
who is not totally desprate. If you pay someone to fo it expect 500
quid a day+, and a few days/weeks work.

In case you are wondering I re-wrote fsck for both BSD and EFS
filesystems.

Using DFSee (as recommended elsewhere) to scan the disc I get:
[This is just the end of the report]

"
Continue scanning : 00003AD2
Bad spot found at : 00003B10 63 sectors SectorRead RC: 1 Cyl: 0 H:240
S:

Continue scanning : 00003B11
Bad spot found at : 00003B4F 63 sectors SectorRead RC: 1 Cyl: 0 H:241
S:

Continue scanning : 00003B50
Bad spot found at : 00003B8E 63 sectors SectorRead RC: 1 Cyl: 0 H:242
S:

Continue scanning : 00003B8F
Bad spot found at : 00003BCD 63 sectors SectorRead RC: 1 Cyl: 0 H:243
S:

Continue scanning : 00003BCE
Bad spot found at : 00003C0C 63 sectors SectorRead RC: 1 Cyl: 0 H:244
S:

Continue scanning : 00003C0D
Bad spot found at : 00003C4B 63 sectors SectorRead RC: 1 Cyl: 0 H:245
S:

Continue scanning : 00003C4C
Bad spot found at : 00003C8A 63 sectors SectorRead RC: 1 Cyl: 0 H:246
S:

Continue scanning : 00003C8B
Bad spot found at : 00003CC9 63 sectors SectorRead RC: 1 Cyl: 0 H:247
S:

Continue scanning : 00003CCA
Bad spot found at : 00003D08 63 sectors SectorRead RC: 1 Cyl: 0 H:248
S:

Continue scanning : 00003D09
Bad spot found at : 00003D47 63 sectors SectorRead RC: 1 Cyl: 0 H:249
S:

Continue scanning : 00003D48
Bad spot found at : 00003D86 63 sectors SectorRead RC: 1 Cyl: 0 H:250
S:

Continue scanning : 00003D87
Bad spot found at : 00003DC5 63 sectors SectorRead RC: 1 Cyl: 0 H:251
S:

Continue scanning : 00003DC6
Bad spot found at : 00003E04 63 sectors SectorRead RC: 1 Cyl: 0 H:252
S:

Continue scanning : 00003E05
Bad spot found at : 00003E43 63 sectors SectorRead RC: 1 Cyl: 0 H:253
S:

Continue scanning : 00003E44
Bad spot found at : 00003E82 63 sectors SectorRead RC: 1 Cyl: 0 H:254
S:

Continue scanning : 00003E83

Elapsed time is : 2851 seconds, throughput 2.81 KiB/sec
16002 Bad sectors found! You can use the 'list' command to show,
or the 'export' command to save the list to a file.
When a buffersize larger than 1 has been used (default),
you can use the '-b:1' option on 'scan' to get
maximum precision and minimum number of bad sectors

"

My tentative conclusion is that the card is totally banjaxed and requires a
reformat at minimum.

I would conclude the same. At this point I would give up on my data.
The physical medium would appear to be damaged in some way.


My other query is:

If there is already a driver mapping the card via the card reader to present
it to the O/S as a disc, will this get in the way of reading and possibly
fixing the raw format of the device?

Now we have establised most disks fake up the cyl/hds/sec figures and
are just lot of sectors, maped onto the physical medium by the disk
controller, you now know thats what the memory card is doing.

Presumably the correct way to get at the basic structure of these memory
cards is to have a card reader with a raw device driver which goes directly
into your program. So effectively you are looking at a piece of RAM and not
a pseudo-disc. I guess you can do this with Unix/Linux but can you do this
with recent versions of Windows?

Unix yes - windoze - no idea.


Cheers

Dave R