-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
df
: Adds support for mount path prefix matching and input path
#3161
df
: Adds support for mount path prefix matching and input path
#3161
Conversation
canonicalization - Sorts mount paths in reverse lexicographical order - Canonicalize all paths and clear invalid paths - Checking of mount path prefix matches input path
src/uu/df/src/df.rs
Outdated
let mut mounts = read_fs_list(); | ||
|
||
// Sort mounts in desc ordered lexicographically | ||
mounts.sort_by(|a, b| b.mount_dir.cmp(&a.mount_dir)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why sort here? On my system (Ubuntu), the output of df
is not lexicographically ordered:
$ df --output=source | tail -n +2 | head -n4
udev
tmpfs
/dev/mapper/vgubuntu-root
tmpfs
See also my comment here: #3086 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My plan is to sort in the order of decreasing mount path length, so that when I do a prefix matching, the longest matching mount path is selected first and rest mount paths are ignored. For example if we have mount paths [\
,\root
] and we have input /root/docs
then we only need to output /root
and /
needs to be skipped. Sorting helps to assure this part.
Sorting in reverse/desc lexicographical order also works here as longest path will come first, but let me change to simple sort by length.
|
…tring length. Added comments for explaining sorting and path prefix matching
6a549ee
to
90ee693
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will cause a regression in df
as it is today, due to the sorting. Unfortunately there is no unit test to cover this case, but the output of df
should match the order of files in /etc/mtab
, as I mentioned in this comment: #3086 (comment)
Also, the various mutations of paths
and the use of the empty string as a way of filtering out paths are tough to follow. Is it possible to move some of this logic into the mount_info_lt()
function, which returns true
exactly when one MountInfo
object should be kept and the other dropped?
It's not possible to move logic into the |
1. Removed sorting of mount paths 2. Implemented prefix matching using iterators 3. Removed un-needed mut from previous commit
I have made changes as below for cleanup of code and meeting requirements
|
Oh you are exactly right:
Sorry for my misunderstanding earlier. In that case, can you add a test for this in |
I have verified that I have confirmed, this test case will only start passing once |
Hi @jfinkels , $ df --output=target /boot /boot /boot
Mounted on
/boot
/boot
/boot |
1. First all input paths are canonicalized 2. If no valid input_paths remain, print filtered_mount_list 3. Else print mount entry for each valid input path
f32ae26
to
a74f74b
Compare
I have checked GNU coreutils df code, and adjusted the helper functions according to it.
Ref: https://github.com/coreutils/coreutils/blob/master/src/df.c#L1830-L1840 Both test cases have been added |
1. Fixed Clippy:needless_late_init 2. Added testcase: check if mount_points are printed in the order of input_paths 3. Added testcase: check if input_path is repeased, is the mount point also repeased
It's best not to view the source code of GNU coreutils in order to avoid infringing their copyright.
There have been a lot of changes in this pull request and it's hard for me to interpret. Could you give concrete examples of how the behavior of
I only see one new test case, asserting that if two files are specified in the input then two identical rows appear in the output table. |
I had to remove the 2nd test case as it will never pass in the CI/CD Pipeline because only one mount point The following are the changes made by this PR:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to add unknown words to the spell-check:ignore
line at the head of the file.
It's hard to say if anything is missing here without tests (which are understandably difficult to create); in the future pull request #3167 demonstrates how we can at least test that these internal helper functions are consistent.
src/uu/df/src/df.rs
Outdated
result.push(mi); | ||
} | ||
} | ||
result | ||
} | ||
|
||
/// Assign 1 `MountInfo` entry to each path | ||
/// `lofs` enries are skipped and dummy mount points are skipped |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "lofs" mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here lofs
is for Solaris style loopback filesystem
which is not present in linux. It's present in Solaris and FreeBSD and is similar to symlink.
…oreutils into df-failed-to-print-fs-info
I had to remove other test case also as it's only working in Linux and fails in Windows. Hence I think unit test cases is the best approach. |
Is that test supposed to only work on unix? Because if so, you could just put |
b92fa2c
to
52a8e2c
Compare
For some reason |
Please let me know if any other changes are required in this PR for getting it merged. |
Adds support for mount path prefix matching and input path canonicalization.
Fixes #3065