On Thu, Mar 19, 2015 at 12:38:46PM +1300, IVP wrote:
> >>I could try moving the file to other blocks on the card, for
> >>example by adding a dummy file to the directory.
> >
> >No, that won't make a difference.
>=20
> What I was thinking was along these lines -
>=20
> File1 starts at 0x00008518, length 0xE44A
> File2 starts at 0x00008527, length 0xEA66
>=20
> File2 is the one that's causing problems
>=20
> Copy File1's start/length to the directory entry for File2, see what happ=
ens
>=20
> Copy File2's start/length to the directory entry for File1, see what happ=
ens
>=20
> I thought I could write a sector to the card using Frhed but it
> seems it can't. I've another utility around here somewhere

Yes, I understand what you mean.

You can certainly do what you like with reads and writes using
commands sent to the card.  Various utilities can be used.  But that's
not my point.

My point is that the firmware in the card, the FTL, maintains a
dynamic mapping table between block numbers and physical flash cells.

block number #1 --> flash cell #4 in page #22921,
block number #2 --> flash cell #8 in page #9193,
block number #3 --> flash cell #2 in page #19944,
etc

There's also a read aging table:

flash page #1 --> read count 233,
....
flash page #9193 --> read count 2289,
....
flash page #19944 --> read count 72,
....

So by manipulating your reads and writes, the only thing you achieve
is to exercise the FTL's mapping and wear levelling algorithm in
slightly different ways.

It means if you get a result, you can't trust it.

--=20
James Cameron
http://quozl.linux.org.au/
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.