Hi, This is slightly off-topic, but given that the gmapsupp.img is a FAT file system, someone on this list might know the answer. Around March 10, the internal file system in my Garmin Edge 705 could no longer be mounted by Linux. I was also unable to convert saved tracks into training runs, which I guess means that the Garmin firmware failed to read the file system as well. Also the base map (gmapbmap.img) failed to load. So, currently the Edge 705 is crippled in that I can see the gmapsupp.img that is on the SD card, but cannot save any tracks. I saved the entire 1GB image from the device to my computer. There is about 23 MB of nonzero data followed by zero bytes. The actual payload may be smaller. It looks like the "boot" sector and all of FAT1 and most of FAT2 are zeroed out. From two Edge 705 users, I got file system dumps. One is from a 512MB model and another is from a 1GB model. Both appear to be further from pristine condition than my file system. I have only created and deleted *.tcx files (saved GPS tracks) and a gupdate.gcd (firmware update). On a copy of my backup image, I already tried replacing the FATs from one of the other dumps, but every combination would cause some important files to be truncated by dosfsck. Because I do not know if there are any unit-specific data stored in the file system, I would like to fix with as small changes as possible. This would mean rewriting only the "boot" sector and the two FATs. Everything starting with the root directory (apparently it is a FAT16 created by mkdosfs) looks intact. Any hints? How could I use dff or some other tool to reconstruct the file allocation tables? Is there a good presentation of the FAT16 file allocation table format somewhere, so that I could try to interpret the tables in a hex editor? Or is there a Linux tool for visualizing or pretty-printing the file allocation tables? Marko