XYplorer Beta Club

It would be nice to also have Rename in the "After file operation" Custom Event Actions.
I currently have a usecase for that feature and was disapointed after I read the Changelog:

Note that "Rename" and "New" are currently not among them.

Is there a good reason not to have Rename in here?

Those operations take a different route than the others.

What is your use case?

Since you asked, here is the long story:
I have created somewhat a mergerFS with junctions.
A directory (lets say C:\DATA\X\) contains junctions to all directories from inside the same structure from multiple other disks (X:\DATA\X\..., Y:\DATA\X\... and Z:\DATA\X\...). The folders inside the X:, Y:, Z: drives have distinct names, so there are no collissions.
This is all fine and working, I allready have a script to create these junctions. All junctions on the C: drive have the exact same names as the directories on the other drives (e.g. C:\DATA\X\a => X:\DATA\X\a, C:\DATA\X\b => Y:\DATA\X\b, etc. I hope you get the idea, of cause there are hundreds sometimes thousands of entries).

Now the usecase:
My working-directory is always C:\DATA\X\ because it contains all the items from multiple disks, but sometimes something needs to be renamed.
When I currently rename an item (e.g. C:\DATA\X\item-a which points X:\DATA\X\item-a) to item-a2 than I also need to manually rename the item on the other drive X:\DATA\X\item-a to item-a2 and also update the target of the junction to keep everthing organized and with a 1:1 mapping.
That is where CEA came to my mind, and I was a little bit disapointed that the Rename-part is not there as this would enable me to fully automate the name and junction-update on the target drive by a simple script.
I also don't want to just delete and recreate non-1:1-matched junctions because the entries in C:\DATA\X\ have a lot of tags in the tag-database.

Why not include the rename part in your simple script? No need to wait for an event, just be the event.

It requires you to do things differently than in "normal operation mode" like inline rename.
The first time you forget to do it you manually have to clean up the mess.
If possible I'd like to see this event as well

Agreed, this is a hole in the CEA net. Will be closed in the next beta.

Hmm, now I think I should have just added it to the already existing "After file operation" event. Why not?!

What do you think as an actual user of this event?

I wouldn't have a problem with that, we can always choose via <CEA_FileOp> what to do next
But you'd keep the new variable names if you move the event (<CEA_RenamedOld> & <CEA_RenamedNew>)?

I could then (ab)use <CEA_SourcePath> and <CEA_TargetPath> (and/or <CEA_SourceList> and <CEA_TargetList>).

I could live with that

Done.

I'll try it once the new beta is out

admin wrote: ↑03 Apr 2024 10:48 Why not include the rename part in your simple script? No need to wait for an event, just be the event.

of cause there are workarounds, but this is the wishes forum, thus I wished it

admin wrote: ↑04 Apr 2024 17:21 Done.

Thank you, now I need to implement the script on my side.

admin wrote: ↑04 Apr 2024 16:25 Hmm, now I think I should have just added it to the already existing "After file operation" event. Why not?!

Thats what I had in my mind when opening the thread here, so I think its perfect.

Works fine so far

You have a typo/copy+paste-bug in the change-notes here: viewtopic.php?p=219646#p219646

You mentioned <CEA_SourcePath> twice. I suppose the one for after rename should be <CEA_TargetPath>.
You might want to fix this for the official changelog