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
Potential bug in fuse's reported block size #4239
Comments
The blockSize constant exists to give exactly that number a name and is documented as such. It won't change. But you're right about the computation. The right size is
|
greatroar
added a commit
to greatroar/restic
that referenced
this issue
Mar 7, 2023
8 tasks
greatroar
added a commit
to greatroar/restic
that referenced
this issue
Mar 7, 2023
greatroar
added a commit
to greatroar/restic
that referenced
this issue
Mar 7, 2023
greatroar
added a commit
to greatroar/restic
that referenced
this issue
Mar 7, 2023
MichaelEischer
pushed a commit
to MichaelEischer/restic
that referenced
this issue
Apr 14, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I happened to stumble across this old pr #447 with this line
restic/internal/fuse/file.go
Line 53 in f646406
I don't think this is doing what you expect. I see two issues:
The blocks field is (unintuitively) supposed to be the "Number of 512 B blocks allocated" - stat(3type), not the number of
blockSize
blocks as it is currently.This isn't an issue at present since
blockSize
is a constant512
, but it will be if the constant is changed in the future.file_size / block_size + 1
isn't a good way of doing "rounded up" integer division since it breaks whenblock_size
divides evenly intofile_size
. For example with this code a file that is 512 bytes or 1 block, this issue means the code would report it as 2 blocks.The text was updated successfully, but these errors were encountered: