File order matters. Files can be overwritten unexpectedly.

[jaekyeom]

Steps to reproduce:

1. Run for i in $(seq 0 9); do touch "file ($i).txt"; done
2. Run vimv *
3. Rename the 10 files from

   file (0).txt
   file (1).txt
   file (2).txt
   file (3).txt
   file (4).txt
   file (5).txt
   file (6).txt
   file (7).txt
   file (8).txt
   file (9).txt
   

   to

   file (1).txt
   file (2).txt
   file (3).txt
   file (4).txt
   file (5).txt
   file (6).txt
   file (7).txt
   file (8).txt
   file (9).txt
   file (10).txt
   

4. All that's left is file (10).txt 😢

[Tr4il]

I just royally messed up, running into this issue. My fault for using this on "production" data, but watch out when using this little tool for changing a sequence a step up or down.

[theoratkin]

I destroyed multiple (thankfully not important) files because of this. For now I switched to vidir from moreutils, it doesn't suffer from this problem and also allows reordering and deleting files.

[opello]

I ran into this and was also annoyed, kind of brute force fixed it, probably not a great implementation:

https://github.com/opello/vimv/commit/4a94aba731116e4397a066e46af3b9c3b3862951

[musjj]

I think vimv can learn from nnn's design. In nnn there's a batch rename mode similar to vimv, but the difference is that each file to be renamed is prefixed by a numeric label. For example:

1 file.txt
2 image.jpg
3 doc.pdf

This way, you can rename/reorder/etc. fearlessly, knowing that each file will be associated correctly. Each labelled line will always be statically associated with the original file path, so there's zero need for the program to make guesses.