Re: Remove/change fs_truncate() API


Andrzej Kaczmarek
 

Hi David,

On Mon, Sep 4, 2017 at 5:17 PM, David Brown <david.brown@...> wrote:
On Mon, Sep 04, 2017 at 09:27:30AM +0200, Andrzej Kaczmarek wrote:

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.

If your goal is posix compliance, this isn't going to be right anyway.
truncate is required to be atomic.

The POSIX truncate call is also allowed to be used to extend the size
of a file.

​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.
 
So do we really need option to truncate any opened file to any size?
In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough. There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.

I think it would be better to return ENOTSUP than to implement it in a
non-compliant way.  My suggestion would be to document it as not
supported, and make a ticket to add support to NFFS for truncation
later.

​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.
 
David

​Best regards,
Andrzej​

Join devel@lists.zephyrproject.org to automatically receive all group messages.