problem with move up from search list

[admin]

OK, the clock/dolly/heater example is simple. But what if folders AND some of their childs are included in the job AND there are name collisions? I don't have the time to look at Flux's script, but does it handle more complex selection patterns?

You know, moving up only one item can already be a surprisingly complex job. I worked about a week on this some years ago. The danger here is undesired overwrites due to collisions.

[kiwichick]

OK, the clock/dolly/heater example is simple. But what if folders AND some of their childs are included in the job AND there are name collisions? I don't have the time to look at Flux's script, but does it handle more complex selection patterns?

I have no idea, Don. I didn't try anything more complicated than what I posted. That's really the only scenario I use. I wouldn't be moving things from different levels or like-named files into the same folder.

If there ever is some way to incorporate this into XY maybe it could work like Rich Copy or Tag Copy where MoveUp from search or branch could trigger a prompt to MoveUp from item location or search location.

[admin]

Made some tests. The possible side effects are too complex. Sorry.

[kiwichick]

All good, Don. Thanks for taking a look anyway :-)

[FluxTorpedoe]

All good here too...

Though just to let you know, the simplistic script just gathers each item's parent folder name and moves them there one by one, that's it!
All the rest (collision management...) being left to XYcopy/Wincopy which logically warn of possible overlaps when necessary.

Never encountered a problem (well, notwithstanding the previous script shortcoming with getpathcomponent()).

Anyway, I just slightly changed the script to only move files that haven't already been moved.
e.g. if folders AND their content are selected to "Power Move Up", the script doesn't try to move the content anymore (less user interaction).

Have a nice day,
Flux

[kiwichick]

Cheers