-
-
Notifications
You must be signed in to change notification settings - Fork 329
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
stat.ino()
is assumed to be small
#1817
Comments
Thanks a lot for bringing this up. For context, the reason this function exists is that the I do not know what drove me to write the Ultimately, I'd think improved documentation should be able to resolve this issue as this truncation is acceptable. |
Doesn't Currently the logic in for Unix-like systems in
That makes sense and suggests a comment-only or comment-and-documentation-only change is the way to go. However, I wonder if the implementation here, or for Especially if no such change can be made, the Relatedly, is it really accurate to say that the gitoxide/gix-index/src/entry/stat.rs Lines 78 to 79 in ffb73b5
Edit: I've opened #1818. |
This expands and slightly corrects the `gix_index::entry::from_fs` documentation: - To be more precise about the expectation of where the metadata come from (it needn't specifically be the `symlink_metadata` function, and it is sometimes even an `fstat`-like function rather than an `lstat`-like function, though not `stat`). - To mention that default values are used for unavailable data. - To mention that truncation is sometimes performed on some fields. Comments are also updated regarding some cases of truncation: why casting down to 32-bit should be okay for `st_dev` and `st_ino` (see GitoxideLabs#1817).
One might think that the
I agree that it's probably wrong to use unix-specific extensions under a
Along with my comment above, I think the documentation could be improved to explain why the custom implementation is needed.
This looks like the doc-string is stale and isn't correct anymore. And I think it can be adjusted to once again say what it does. |
Current behavior 😯
gix_index::entry::Stat::from_fs
obtains information from astat
structure on like this on all Unix-like systems:gitoxide/gix-index/src/entry/stat.rs
Lines 94 to 110 in ffb73b5
But even if that the rationale holds for Linux, it is not clear that the device number always fits in a 32-bit integer without loss of information, because enormous device numbers do exist on some notable Unix-like operating systems with some filesystems. It is furthermore not accurate that such large numbers are impractical, because devices need not be assigned sequentially. For example, this forum discussion pertains to huge device numbers for ZFS volumes on FreeBSD.
In addition, I am not confident this holds on Linux, since even on the same architecture there is more than one stat-related syscall. This reference of syscalls gives stat as an example of an entry point with multiple syscalls on the same platforms that use data types with different sizes.
Expected behavior 🤔
I don't know if this actually causes a problem. This issue is thus incomplete in that I am not sure what happens with such devices. Maybe the truncation is okay? But it is not obvious why it would be.
However, even if the implementation is not changed, the comments should be revised, once the effect is known, to avoid implying that device numbers must be sequential or that the field fits in 32-bits on all systems, and to explain either:
u32
, orGit behavior
It looks like Git is similar. On most systems,
unsigned int
is 32-bit, even ifunsigned long
is 64-bit, and Git defines:Which is populated like this:
It is not clear that this is intended in Git either. Other lossy conversions are identified as such.
Steps to reproduce 🕹
I don't currently have a procedure to attempt to produce any incorrect runtime behavior based on this. I am unsure if it is only the comment that should be corrected, or if the representation and/or runtime behavior should also be changed.
The text was updated successfully, but these errors were encountered: