On Freitag, 2. September 2016 10:53:08 CEST you wrote:
Adding this to the current test script is somewhat problematic. The test runs all tests for fat and ext4, so each testcase should be file system agnostic. Unfortunately fat and ext4 (at least as implemented in U-Boot) have different semantics, as ext4 in U-Boot requires all path to absolute paths, whereas fat seems to require something else (relative path? absolute path, but without leading '/'?).
Calling 'fatwrite host 0 0 /. 0x10' happily creates a directory! called '/.', 'fatwrite host 0 0 /./foo 0x10' creates a file and copletely messes up the filesystem (according to fsck.vfat and mounting the fs in linux).
Any advise?
Can we fix this up in the argument parsing? This sounds like it's showing some bugs in the fatwrite parsing code itself.
The fatwrite code is hardly doing any parsing at all. It does not strip any "/" or "" characters, does not interpret these as dir delimiters, and just pushes whatever it gets into the directory.
For the lookup, it uses a function which is quite similar to the fatload/fatls function, but still different. It only traverses the root directory.
The whole fatwrite seems to be a 50% almost verbatim copy of the read implementation and shares hardly any code. The problem is the "almost" copy, most functions have minor differences.
I think lots of code could be removed from fatwrite if the read implementation where better structured, but e.g. the main entry point is a huge function which, depending on some flags either prints the directory listing while walking/traversing the tree, returns the file size, loads a specified file into a buffer, or errors out in case some path element was not reachable.
So, currently there are two options for the bad fatwrite behaviour: a) add even more duplicate code to fatwrite b) restructure fatread to be reusable
Opinions, please!
Kind regards,
Stefan