-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
What version of ripgrep are you using?
ripgrep 11.0.2
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)
How did you install ripgrep?
apt-get
What operating system are you using ripgrep on?
5.15.0-33-generic #34~20.04.1-Ubuntu SMP Thu May 19 15:51:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Describe your bug.
When using the vim plugin LeaderF, which uses rg as its search engine, I realized that the sorting order seems to be "randomly" incorrect.
After a bit of tweaking, I produced a minimal script reproducing the issue.
What are the steps to reproduce the behavior?
Under a clean temporary folder:
echo string > modified_first; sleep 1; mkdir -p dir; echo string > dir/modified_second; find -type f | xargs stat
At this point, rg returns the correct order when executing:
rg --sort modified string
However, if we modify the two files now, the order becomes incorrect:
echo string > modified_first; sleep 1; mkdir -p dir; echo string > dir/modified_second; find -type f | xargs stat # as the output shows, "./modified_first" is modified before "./dir/modified_second"
Now if we run rg --sort modified string
, we find the following output:
dir/modified_second
1:string
modified_first
1:string
when the expected behavior should be:
modified_first
1:string
dir/modified_second
1:string
I'm attaching the full transcript with output below:
l14:~/tmp/ripgrep$ echo string > modified_first; sleep 1; mkdir -p dir; echo string > dir/modified_second; find -type f | xargs stat
File: ./modified_first
Size: 7 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 9699609 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2022-06-23 22:29:05.404139561 -0400
Modify: 2022-06-23 22:29:05.404139561 -0400
Change: 2022-06-23 22:29:05.404139561 -0400
Birth: -
File: ./dir/modified_second
Size: 7 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 9699610 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2022-06-23 22:29:06.412148288 -0400
Modify: 2022-06-23 22:29:06.412148288 -0400
Change: 2022-06-23 22:29:06.412148288 -0400
Birth: -
l14:~/tmp/ripgrep$ rg --sort modified string
modified_first
1:string
dir/modified_second
1:string
l14:~/tmp/ripgrep$ echo string > modified_first; sleep 1; mkdir -p dir; echo string > dir/modified_second; find -type f | xargs stat
File: ./modified_first
Size: 7 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 9699609 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2022-06-23 22:29:12.280199102 -0400
Modify: 2022-06-23 22:29:20.040266325 -0400
Change: 2022-06-23 22:29:20.040266325 -0400
Birth: -
File: ./dir/modified_second
Size: 7 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 9699610 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ user) Gid: ( 1000/ user)
Access: 2022-06-23 22:29:12.280199102 -0400
Modify: 2022-06-23 22:29:21.044275025 -0400
Change: 2022-06-23 22:29:21.044275025 -0400
Birth: -
l14:~/tmp/ripgrep$ rg --sort modified string
dir/modified_second
1:string
modified_first
1:string
l14:~/tmp/ripgrep$
Potential explanation
I don't quite understand why this issue pops up, but I realized that this error does not exist if modified_second
is not under dir
directory.
So I did a touch dir
, which seems to give the correct order. My speculation is that, --sort modified
somehow takes into consideration the modtime of a file's parent directory instead of the file itself