On Wed, 28 Jul 2010, Peter Stuge wrote: > Alan Stern wrote: > > > 1483 lines of debug output is at http://stuge.se/lpc1343_isp.txt > > > (Is it OK to send the 115kb log to the list?) > > > > The debug output is a little odd; there are no writes to sector 2 > > (which I would expect to contain a second FAT). > > Also on a 34 kb small filesystem? Why not? It would fit, since each FAT needs only 51 bytes and there are two sectors available. But it turns out this device has only one FAT, and it lets the FAT take up two sectors. Maybe for alignment purposes; I don't know. > > dd if=/dev/sdb count=7 | hexdump -C > > http://stuge.se/lpc1343/dd_1_mount.txt 1202 bytes > http://stuge.se/lpc1343/dd_2_rm.txt 965 bytes > http://stuge.se/lpc1343/dd_3_cp.txt 1360 bytes > http://stuge.se/lpc1343/dd_4_umont.txt 1360 > http://stuge.se/lpc1343/dd_5_flushbufs.txt 1360 bytes > http://stuge.se/lpc1343/dd_6_reset.txt 1202 bytes > --8<-- diff -u dd_[13]* > --- dd_1_mount.txt 2010-07-28 02:03:20.000000000 +0200 > +++ dd_3_cp.txt 2010-07-28 02:03:44.000000000 +0200 > @@ -3,17 +3,19 @@ > 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > * > 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| > -00000200 f8 ff ff 03 40 00 05 60 00 07 80 00 09 a0 00 0b |....@..`........| > +00000200 f8 ff ff ff 4f 00 05 60 00 07 80 00 09 a0 00 0b |....O..`........| > 00000210 c0 00 0d e0 00 0f 00 01 11 20 01 13 40 01 15 60 |......... ..@..`| > 00000220 01 17 80 01 19 a0 01 1b c0 01 1d e0 01 1f 00 02 |................| > -00000230 21 f0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 |!...............| > +00000230 21 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |! ..............| > 00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > * > 00000600 43 52 50 20 44 49 53 41 42 4c 44 28 00 00 00 00 |CRP DISABLD(....| > 00000610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > -00000620 46 49 52 4d 57 41 52 45 42 49 4e 20 18 bc 41 97 |FIRMWAREBIN ..A.| > -00000630 37 38 37 38 00 00 45 51 46 3a 02 00 00 80 00 00 |7878..EQF:......| > -00000640 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > +00000620 41 6f 00 72 00 69 00 67 00 69 00 0f 00 e7 6e 00 |Ao.r.i.g.i....n.| > +00000630 61 00 6c 00 2e 00 62 00 69 00 00 00 6e 00 00 00 |a.l...b.i...n...| > +00000640 4f 52 49 47 49 4e 41 4c 42 49 4e 20 00 00 74 10 |ORIGINALBIN ..t.| > +00000650 fc 3c fc 3c 00 00 74 10 fc 3c 03 00 00 80 00 00 |.<.<..t..<......| > +00000660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > * > 00000800 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| > * This tells what actually happened. Maybe at this point you don't care any more, but it's nice to know the answer. As you might expect the file initially occupies successive sectors, starting with sector 4 and going up to sector 67, for a total of 64 sectors = 32 KB. However after the copy, the new file starts in sector 6 and goes up to sector 67, with its final two sectors stored in 4 and 5. Therefore that 1024 bytes of extra 0's you see at the beginning are actually the _last_ 1024 bytes of the file. The reset operation overwrites the FAT contents and the root directory, leaving it looking as though the file starts in sector 4 again even though it doesn't really. Don't ask me why Linux allocates the file's sectors this way. On the other hand, this does suggest that things would work out correctly if you copied the new file over the existing one instead of erasing the old file first, since then each part of the file would be stored in the same sectors as before. Alternatively, without even mounting the filesystem you could do: dd if=newfile.bin of=/dev/sdb seek=4 which would write the new data directly to the device starting at sector 4, where it belongs. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
