On Tue, Sep 05, 2017 at 10:18:01AM +0200, Andrzej Kaczmarek wrote:
I'm not really sure if this needs to be POSIX compliant - the Jira ticket forPerhaps we should change the API to add the truncate option to
fs_open(), at least provided at least one underlying implementation
Yes, currently I return ENOTSUP for this. My only concern here is that thisOnly if the fs_truncate() for 0 offset can be implemented atomically.
I'm not sure how that would work for operations given by file
descriptor, since the file is already opened.
I think there should be as little between the Zephyr fs API and the
NFFS API. A developer using a filesystem on an embedded system needs
to understand what is happening (and specifically what will happen if
power is interrupted during an operation). That means we should avoid
having API calls that try to simulate behavior that isn't there.
For example, if fs_truncate() somehow were to use fs_open() by
figuring out the filename the existing file descriptor used, and
opening with truncation in NFFS, this would cause an additional file
descriptor to be used for the operation (even if just momentarily).
In a system design, it is possible that the developer will configure
the exact number of file descriptors available, which could cause this
operation to either mysteriously fail, or succeed, but use the file
descriptor temporarily, causing another thread's filesystem operation
So, my suggestion would be to add the O_TRUNC (or equivalent) flag to
open, make fs_truncate() return ENOTSUP, and just document this. If
arbitrary truncation, or truncation of an open file is desired, that
can be added later to NFFS, and then to the API.