-
Notifications
You must be signed in to change notification settings - Fork 47
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
Fix dir::get_size
's handling of symlinks
#60
Conversation
This makes `dir::get_size` give a correct calculation of the size of a path of directory, that now matches that returned by eg: `du --bytes -s <path>`. Before: - Symlinks were followed, causing double-counting of symlinked files (see webdesus#59). - Whilst the metadata size of subdirectory entries was counted correctly, the metadata size of the parent directory (the initial `path` passed into `dir::get_size`) was not counted. See: webdesus#25 (comment) Now: - Symlinks are no longer followed (fixing the regression from webdesus#34), so that only the size of the symlink itself is included (as expected), and not the size of the symlink's target. - If the initial `path` passed into `dir::get_size` is a directory, the size of that directory entry itself is now correctly counted (like it was already being counted for subdirectories). Fixes webdesus#25. Fixes webdesus#59.
dir::get_size
's handling of symlinksdir::get_size
's handling of symlinks + directories
Hi @edmorley! Thank you for your incredible work!!! I check and fix fall tests this week and will accept this PR😊 |
@webdesus Thank you! Did some tests fail locally for you? The test I added passed locally for me (macOS). |
@edmorley yes locally, not yours test, others:
I looked at the reason. I made this decision on purpose not to count the size of the folders.
I suggest the following edit: let mut size_in_bytes = 0; // FIRST CHANGE.
if path_metadata.is_dir() {
for entry in read_dir(&path)? {
let entry = entry?;
let entry_metadata = entry.metadata()?;
if entry_metadata.is_dir() {
size_in_bytes += get_size(entry.path())?;
} else {
size_in_bytes += entry_metadata.len();
}
}
}else{
size_in_bytes = path_metadata.len(); // SECOND CHANGE
}
Сonsider only files. What do you think about it? |
@webdesus Hi! Thank you for the reply. So for me However if you prefer for However, if |
@webdesus Hope you are well :-) Any thoughts on the above? |
Hi, @edmorley! |
@webdesus No problem about the delay, I know the feeling! :-) I'm fine with you merging that change, thank you. (I still think the implementation should count directory sizes too, but will just be happy to get the other fixes in, since they are a bigger problem.) |
dir::get_size
's handling of symlinks + directoriesdir::get_size
's handling of symlinks
I think it is sometimes reasonable too. But this API work a long time, and I think we can do it in another feature. |
This makes(Due to changes requested during review, this is no longer the case.)dir::get_size
give a correct calculation of the size of a path of directory, that now matches that returned by eg:du --bytes -s <path>
.Before:
dir::get_size
returns wrong size for symlinks #59).path
passed intodir::get_size
) was not counted. See:Unexpected behaviour of dir::get_size #25 (comment)
Now:
If the initialDue to changes requested during review, this is no longer the case. The metadata size of the directory entries (entries only, not the contents) is now excluded entirely from the total size.path
passed intodir::get_size
is a directory, the size of that directory entry itself is now correctly counted (like it was already being counted for subdirectories).In addition, the size calculations are performed using
DirEntry::metadata
, rather than unnecessarily converting to a path and then passing that path tofs::{metadata,symlink_metadata}
.Fixes #25.
Fixes #59.