Re: Remove/change fs_truncate() API
On Mon, 4 Sep 2017 09:27:30 +0200
Andrzej Kaczmarek <andrzej.kaczmarek@...> wrote:
Hi,ENOTSUP is your friend (except Linux thinks it should be EPERM, see
So do we really need option to truncate any opened file to any size?POSIX has it:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/ftruncate.html , so we
apparently need it too.
In Mynewt there's only option to truncate file to 0 when opening it byIn a Linux system, only 0.0001% or so of the source code belongs to the
kernel. With that ratio in mind, how many Zephyr applications have you
My proposal would be one of:Let's have a look at https://linux.die.net/man/2/ftruncate :
truncate(): /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L
ftruncate(): /* Since glibc 2.3.5: */ _POSIX_C_SOURCE >= 200112L
So, ftruncate() was categorized in glibc since the break of the century,
while truncate()-by-path is much more of a novelty, which should set
a priority of the order of their support.
The reason why I'd prefer to have truncation done by *path* instead ofThis seems like a logical fallacy: you have a problem with a single
thing on your hands (NFFS) and you want to change the world around it
(Zephyr API). Just accepting that NFFS is a novel, unproven,
underdeveloped and undertested filesystem should give enough of a
solution: just treat ftruncate operation as unsupported on it. Another
solution of course is to fix NFFS to support a standard POSIX
filesystem operation repertoire.
Let's look at https://linux.die.net/man/2/ftruncate again:
The underlying file system does not support extending a file beyond its
However, my local man has more of it:
EPERM The underlying filesystem does not support extending
a file beyond its current size.
EPERM The operation was prevented by a file seal; see fcntl(2).
So, in Linux, EPERM is ambiguous. There's actually a better error code
- ENOTSUP. Arguably, it's the same "POSIX drama" as with EPERM vs
EACCESS, vividly explained here:
Following the same logic, I'd recommend to use ENOTSUP here (then wait
until Zephyr's POSIX subsystem matures, apps getting ported, and break
because of the "non-Linuxy" error code is used, then we switch it to
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog