Skip to content

Conversation

@nkraetzschmar
Copy link
Contributor

For some low-level filesystem operations it can be beneficial to both get the cluster chain of a given file as well as querying where exactly on disk the file contents reside.

Examples where such info might be useful:

  • Perform secure erase
  • Detect file fragmentation
  • Pass Disk byte offset or LBA to a different tool that can work with it

This PR adds two functions, one to just expose the internal getClustersList via the File type.
The other to express the same info directly in disk areas, where each area is described by its starting byte and a length in bytes. (further conversion to disk sectors / LBA can be easily performed by the caller.)

Copy link
Collaborator

@deitch deitch left a comment

Choose a reason for hiding this comment

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

Looks good to me, and I appreciate the description of the use cases. Maybe add those to the docs (even just the inline), so someone looking at this in 6 or 12 months and wonders why we would expose such details, can see?

Also there is a linting error.

@nkraetzschmar
Copy link
Contributor Author

sorry for the delay, added the use cases to the inline docs and fixed the linter errors now

@deitch deitch merged commit 31082f1 into diskfs:master Dec 9, 2024
20 checks passed
@deitch
Copy link
Collaborator

deitch commented Dec 9, 2024

No problem. Thanks for contributing.

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