Skip to content

Strange behavior of --sort modified, giving incorrect order #2243

@qx220

Description

@qx220

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugA bug.help wantedOthers are encouraged to work on this issue.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions