The release 2.6 of littlefs should soon include the fix for the bug that makes this PR fail littlefs-project/littlefs#814

Rebased on top of #42 , so the tests pass now

Can you please rebase again?

Thinking about how to make this available from the core crate.

Making this available from core would need breaking changes, and would introduce the DirIterationTell struct to be part of the DynFilesystem trait, which would be weird.

As part of the trussed ecosystem this is only needed in the core trussed backend which already depends on the full littlefs2 and not the core.

As part of the trussed ecosystem this is only needed in the core trussed backend which already depends on the full littlefs2 and not the core.

But since trussed-dev/trussed#144 it uses DynFilesystem for filesystem operations, and since trussed-dev/trussed#195 it no longer has access to the Filesystem at all.

Could we add a new function to DynFilesystem that uses a custom iterator trait that provides access to seek and tell?

Oh right.

Surprisingly cargo-semver-checks does not flag this as a breaking change in core.

I'm investigating further if this is not a false positive

I actually see no way of exposing this as part of littlefs2-core without making this a breaking change.

This is a breaking change because an existing implementation of DynFilesystem would not provide the callback with an implementation of the DirIterator. Adding a new method is hazardous because the new one would not be able to provide a default implementation of tell, seek (though one could do with a wrapper struct that uses indices) but especially rewind.

I could see adding a new dyn compatible trait (with better names):

pub trait DynFilesystemV2: DynFilesytem {
    fn read_dir_and_then_unitv2(…);