No refresh of search tab after a rename operation

[JoTo]

Using XYplorer 9.90.0202 beta
WinXP and Win7-64

Hi Donald,

today i faced a situation that i think need to point you at. Not a big deal/vital problem though.

Following steps:
1. Search some files by filename and let the results show up in a search tab
2. Select some/all files in the search tab and use context menu "Rename special"->"German Umlauts ä->ae"
3. Without losing the selection do another special rename (e.g. aaa aaa -> Aaa Aaa)

Then you get error messages that the system can't find the path of that items in the list that are renamed at the first rename (the umlauts rename).

Seems that the search tab don't respect the already name changed items (ä->ae).

I'm not sure if its wise to update the whole search tab, as this can take loooot of time if the search is going over hundreds of thousands of files. Either you can update only the changed items in the search tab list directly (while renaming operation) or you may popup a dialog when doing a second rename on a search tab when filenames have changed in a prior one. *Shrug* Or you find a another and genius solution as always.

Thanks for reading. XY is still my most important and satisfying all-day-lifesaver app i own. *Pat on Donalds shoulder*

Greetings
JoTo

[admin]

Do you have auto-refresh on and does the display update?

I cannot reproduce it with files, but when a folder has been renamed and any files under this folder are listed in the search results then indeed they are not correctly updated. Can you confirm this?

[JoTo]

Hi Donald,

please take my apoligies that i mixed up things a bit here. The tab i mentioned is labeled "search results", but it doesn't came from a "search". I used "Show all items in branch" showing a whole tree with folders AND files.

Then i selected ALL (folders AND files) in that tab and renamed umlauts. After that i tried to do a "every word uppercase" rename. Then i got the previous containing umlauts files to be not found.

Sorry again for being such a lamer, reporting wrong information in my "how to reproduce".

I am still not sure if the display updates. That i have to try again, if you still can't reproduce the case.

Thx. and greetings again
JoTo

[JoTo]

Hmmm, no edit post option, or do i oversee it?

I just tried it again. Now i get an earlier error.

I created the following test case tree:
- test <dir>
- Februar <dir>
- Nödel.txt
- ranz.txt
- März <dir>
- Nödel.txt
- ranz.txt

I used "show all items in brach" in test, then selected all items (incl. folders and files), then i tried to rename umlauts "ä->ae", and i get an error that the system can't find the path to "nödel.txt" in the "märz" dir.

After confirming the dialog i get the following result:
- März dir was renamed to Maerz
- Februar dir was left untouched (as expected)
- ranz.txt was left untouched in both dirs (as expected)
- nödel.txt was renamed to noedel.txt in Februar dir, but was left untouched in Maerz dir

So yes, seems you are right and it has something to do with renamed folder and containing files in that already renamed folders then.

Maybe you need to go bottom up from the tree when renaming. And rename ancestors last, when all children are already renamed.

But i think that is difficult to do and maybe not worth the effort. Everybody can resolve the problem by closing the tab and do a new "show all items in branch" or search to the the updated list.

I leave it to your decision if you want to spend any time on this issue.

Greetings
JoTo

[admin]

Yes, this is what I thought. If you do a bulk rename that contains folders and their contents you will run into problems when the folders are renamed before their contents. Smarter sorting of the rename jobs could solve this probably (I make a note for later).

Anyway, your post helped me to fix a bug.

[admin]

Should work better in next version...

[JoTo]

Hi Donald,

thanks! Glad if i helped in any way.

And thank you to you, that you are a so responsive and kind developer.

Greetings
JoTo