Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return an error when encountering corrupted lfn entry #32

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

aurelj
Copy link
Contributor

@aurelj aurelj commented Jul 26, 2024

Without this, on a corrupted fs, I get hundreds of "corrupted lfn entry!" messages printed thru defmt for a single read_dir_entry() call.

Copy link
Owner

@MabezDev MabezDev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I'm not so sure about this change.

CorruptedFileSystem should only be returned when something critical to the operation of the FS has gone wrong, either the boot sector is corrupted or fsinfo is. Imo corruption of a single file or in this case file name entry is not a reason to return this error.

Do defmt logs really matter that much? IIRC I think there is a way to disable defmt logs for a certain crate module: https://defmt.ferrous-systems.com/filtering.html.

@aurelj
Copy link
Contributor Author

aurelj commented Sep 12, 2024

Indeed, I agree CorruptedFileSystem is probably not an appropriate error for this.

But filtering defmt logs sounds a bit hacky and adds the risk of missing some other unrelated and important messages.

process() is only called by DirIter.next() which already return errors in various situations, so it really seems logical that in case of corrupted lfn entry, DirIter.next() returns some kind of error.
So I propose adding a new Error enum value for this situation, such as CorruptedFileEntry.
Does it sound better to you ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants