Removed invalid overwrite for return value.

[lmapii]

While working on a littlefs integration I've received the return value LFS_ERR_NAMETOOLONG for several error scenarios where it doesn't apply. I think the affected line may have been copied by mistake.

E.g., I've received this return value for an invalid block device driver where I've messed up the offsets within the memory and also with bugs in an optimized CRC32 calculation.

[geky]

Hi @lmapii, thanks for the PR. This definitely shouldn't mask all errors like it is.

The original motivation for that condition was to handle a difficult case where the file name doesn't fit in our metadata blocks. For example a 256 byte file name will never fit in a 128 byte block (which is in theory allowed for littlefs but causes problems like this one).

Looking into this more, maybe we should consider adding a new error (LFS_ERR_2BIG?) to differentiate between running out of storage (LFS_ERR_NOSPC), filename too long (LFS_ERR_NAMETOOLONG), and this errro which occurs due to geometric limitations in littlefs.

At the very least, this shouldn't catch/hide all errors. We should change this to only change the error for LFS_ERR_NOSPC.

[geky]

Consider change this to if (err == LFS_ERR_NOSPC) {

[lmapii]

I was about to add the following change:

        // it can happen that the file name doesn't fit in the metadata blocks, e.g., a 256 byte file name will
        // not fit in a 128 byte block
        err = (err == LFS_ERR_NOSPC) ? LFS_ERR_NAMETOOLONG : err;
        if (err) {
            goto cleanup;
        }

But I'm not sure if that would resolve the issue that I've stumbled upon, since then again I would receive LFS_ERR_NAMETOOLONG. My scenario was quite special though in the sense that I've had bugs in my integration (both block device driver and the CRC function, which I've changed to use available CPU instructions). My favourite resolution would simply be a comment documenting your case and return the original error code.

[lmapii]

The original motivation for that condition was to handle a difficult case where the file name doesn't fit in our metadata blocks. For example a 256 byte file name will never fit in a 128 byte block (which is in theory allowed for littlefs but causes problems like this one).

To be honest I'm not too familiar with the details of littlefs since simply thus far it worked so well that I didn't have to :). My question is this:

• Would this case you're describing be a configuration error, meaning the block size supported by the configuration and the block device driver do simply not match the file name configuration,
• Or can this happen during runtime, e.g., when there's not enough space to create this last metadata block?

In both cases LFS_ERR_NOSPC would be my favourite, I'd also not think that adding a new error code would be necessary since in any case one would end up debugging their case.

Adding a comment to describe either scenario would be very helpful.

[geky]

• Would this case you're describing be a configuration error, meaning the block size supported by the configuration and the block device driver do simply not match the file name configuration,
• Or can this happen during runtime, e.g., when there's not enough space to create this last metadata block?

I think the problem is that LFS_ERR_NOSPC can mean both of these...

In the first case LFS_ERR_NOSPC means the block_size is too small to fit all of the metadata (file names and custom attributes make this not determinable at compile time).

In the second case LFS_ERR_NOSPC means the there are no more blocks available. This can happen on any lfs_dir_commit, since wear-leveling may need to move the directory to a new block.

(The reason LFS_ERR_NAMETOOLONG isn't returned by lfs_dir_commit is because internally lfs_dir_commit is committing various types of "attributes" such as file names, file sizes, pointers, etc.)

In hindsight we probably should have used a different error, perhaps LFS_ERR_2BIG (-7), since these are fundamentally different types of errors. But this would be a bigger change and probably API breaking...

In both cases LFS_ERR_NOSPC would be my favourite, I'd also not think that adding a new error code would be necessary since in any case one would end up debugging their case.

I may be biased as a maintainer, but the number of issues I've seen so far about mostly empty filesystems returning LFS_ERR_NOSPC suggest it's not a good error code outside of strictly "no more blocks left". Perhaps because this is its purpose on most other filesystems :)

[lmapii]

Ok I see how there are other use-cases which might affect more users. I've updated the PR to only convert the LFS_ERR_NOSPC error to LFS_ERR_NAMETOOLONG as you suggested, I hope that fits your need. Notice that your proposed change of if (err == LFS_ERR_NOSPC) should not have worked since we would not have left the function in case of an error anymore (?).

[geky]

Thanks for the PR!