summaryrefslogtreecommitdiff
path: root/fs/ubifs
diff options
context:
space:
mode:
authorStefan Brüns <stefan.bruens@rwth-aachen.de>2016-09-06 04:36:55 +0200
committerTom Rini <trini@konsulko.com>2016-09-23 09:02:44 -0400
commitde9e831675d72c08c2cc3361a8e9b413ff3facec (patch)
tree174bdeba3cc3ddeb6766bdf652aec0da4f55e4f6 /fs/ubifs
parentb779e0290a4a6ac589bfac7192b4f8e677d3bf8a (diff)
downloadu-boot-imx-de9e831675d72c08c2cc3361a8e9b413ff3facec.zip
u-boot-imx-de9e831675d72c08c2cc3361a8e9b413ff3facec.tar.gz
u-boot-imx-de9e831675d72c08c2cc3361a8e9b413ff3facec.tar.bz2
ext4: Correct block number handling, empty block vs. error code
read_allocated block may return block number 0, which is just an indicator a chunk of the file is not backed by a block, i.e. it is sparse. During file deletions, just continue with the next logical block, for other operations treat blocknumber <= 0 as an error. For writes, blocknumber 0 should never happen, as U-Boot always allocates blocks for the whole file. Reading already handles this correctly, i.e. the read buffer is 0-fillled. Not treating block 0 as sparse block leads to FS corruption, e.g. ./sandbox/u-boot -c 'host bind 0 ./sandbox/test/fs/3GB.ext4.img ; ext4write host 0 0 /2.5GB.file 1 ' The 2.5GB.file from the fs test is actually a sparse file. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Diffstat (limited to 'fs/ubifs')
0 files changed, 0 insertions, 0 deletions