spiffs icon indicating copy to clipboard operation
spiffs copied to clipboard

SPIFFS_USE_MAGIC_LENGTH not robust

Open pjsg opened this issue 9 years ago • 1 comments

I had hoped that by enabling SPIFFS_USE_MAGIC_LENGTH and SPIFFS_USE_MAGIC then detection of a file system image would be reliable.

Unfortunately, it appears as though if the region from (say) 0 to 1Mbyte is a valid file system, then (unfortunately) the region from 0x10000 to 1Mbyte is also a valid filesystem (according to the SPIFFS_probe_fs function). This is really unfortunate!

I think that changing the definition of SPIFFS_MAGIC to

#define SPIFFS_MAGIC(fs, bix)           \
  ((spiffs_obj_id)(0x20140529 ^ SPIFFS_CFG_LOG_PAGE_SZ(fs) ^ ((fs)->block_count - (bix < 3 ? bix : (bix<<1)))))

ought to work. (Well, it seems to work within nodemcu).

The key point is to make sure that only the first three blocks have the appropriate offset between the magics.

Actually, now I think about it some more, even with the above code, there is a chance that the probe would match block 1, block 2 if block 3 was partially erased. This is a much smaller chance, but ought to be closed as well.

pjsg avatar Aug 29 '16 02:08 pjsg

It is stated in the comment for SPIFFS_probe_fs that One must be sure of the correct page size and that the physical address is correct in the probed file system when calling this function. It is not checked if the phys_addr actually points to the start of the file system, so one might get a false positive if entering a phys_addr somewhere in the middle of the file system at block boundary.

You can however probe iterativelly from lower to higher addresses. Say you know the FS lies on a 0x10000 boundary - you start probing 0x00000, then 0x10000, then 0x20000 until you get a positive. The other way around is also possible: getting a false positive for e.g 0xf0000, you can probe backwards until it fails. The lowest successful probe would be the start of the system.

Also, in your example you find a fs @ 0x00000 being 1 meg big. Then you should skip all addresses from 0x00000 and 1 meg forwards.

I will (probably) not fix this now. Number of magic bits depends on spiffs_object_id type, and on some systems I simply cannot cram in more info to get a reliable magic. However, as we discussed in #99, an upcoming spiffs version 0.4 will solve this problem and make the probe independent of where you sample the FS. It will be a better solution altogether rather than patching current. Also, this way I will not break backward compatibility twice.

pellepl avatar Aug 29 '16 19:08 pellepl