Re: Remove/change fs_truncate() API

David Brown

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 for
adding filesystem APIs states that it is designed after POSIX but is not POSIX
compliant. For example, fs_open() does not have flags which could be used to
truncate existing file when opening, so it would cover one of possible
scenarios here. But perhaps something changed since then, don't know.
Perhaps we should change the API to add the truncate option to
fs_open(), at least provided at least one underlying implementation
supports this.

Yes, currently I return ENOTSUP for this. My only concern here is that this
means there is no way to open existing file and truncate it other than
fs_unlink() + fs_open() due to missing flags in fs_open() I mentioned above.
BTW, does it make sense to have fs_truncate() work for '0' as offset and return
e.g. EINVAL for other values? This should be doable I think.
Only 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
to fail.

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.


Join to automatically receive all group messages.