#12932 NORM Not Tri: fs-save falsely reports success on vfat targets

[Zarro Boogs per Child]

#12932: fs-save falsely reports success on vfat targets
-------------------------------------+-------------------------------------
            Reporter:  fatalbert     |          Owner:  Quozl
                Type:  defect        |         Status:  new
            Priority:  normal        |      Milestone:  Not Triaged
           Component:  ofw - open    |        Version:  Development
  firmware                           |  firmware
          Resolution:                |       Keywords:
          Blocked By:                |       Blocking:
Deployments affected:                |  Action Needed:  reproduce
            Verified:  0             |
-------------------------------------+-------------------------------------

Comment (by fatalbert):

 > how was the media formatted?

 Originally I formatted on a Debian Stretch system using ''fdisk'' followed
 by ''mkfs.vfat''.  Then I also used open firmware for the formatting
 (triggered by your suggestion above), using the latest release
 ("`q7c07`").  Success was still reported while producing a file of around
 ~3.6gb.\\

 I'm a bit baffled that fat32 could ever work with 8gb of internal storage.
 If you were to adapt the code to support fat32 files larger than 4gb, it
 would likely be a departure from the fat32 spec, but also I would expect
 overcoming that limitation would be quite non-trivial since it's likely
 based on a fixed field width in the table.\\

 > no, it's not a security bug

 The training for my M.S. in infosec indoctrinated me to treat all threats
 on data ''integrity'' or ''availability'' as security threats.  That's per
 the discipline; perhaps OLPC has an internal definition for security.
 When the ''fs-save'' operation produced an uncompressed image less than
 half the size of the content it was imaging, loss of data integrity alarm
 bells go off in my head.  And then if the user later restores from that
 partial image, we would also expect a loss of ''availablity'' to
 manifest.\\

 Anyway, I worked around the bug and won't be bothered if it goes unfixed,
 but someone trusting the program output and neglecting filesize could get
 stung by it.

 > we made significant changes to ext2, ext3, ext4, fat16 and fat32
 filesystem support since initial release.

 I found the `d# <megs> fat32-partition u` command, but I could not find
 any command in the documentation or by ''sifting'' in forth to do ''ext''
 formatting in openfirmware.

--
Ticket URL: <http://dev.laptop.org/ticket/12932#comment:2>
One Laptop per Child <http://one.laptop.org/>
One Laptop per Child bug tracking system