XYplorer Beta Club

Loaded fined when stored under <xyscripts>.
Tested on a huge (~2500 files) source folder and nothing - stopped at the "generating"... part (will left script running and see what happens).
Tested on a simple "11 files/total" folder and worked. Perfectly! The report part is great.
-what happens if I click on other folder/tab while report is being generated?
-does it stores any info on any .ini file I'm not aware of?
Thank you!

EDIT: -what happens if I click on other folder/tab while report or any other operation performed by script is in execution? Is it safe playing around while I wait?

SkyFrontier wrote:Tested on a huge (~2500 files) source folder and nothing - stopped at the "generating"... part (will left script running and see what happens).

Yes, this really isn't meant to be used for ghosting a whole drive. It will get the work done, but within the confines of XY scripting it is going to take a while, especially to walk the directories to discover all of the contents (this is a delicate recursive process that can very easily overflow the stack). I can't imagine what possible use you'd really have for using this on huge folders, or more honestly, why you want to do this for any folder.

-does it stores any info on any .ini file I'm not aware of?

All of the settings are stored at the bottom of the script file (hence why it must be run from a file). And the structure of the file is delicate to ensure that part continues to function.

-what happens if I click on other folder/tab while report is being generated? ... EDIT: -what happens if I click on other folder/tab while report or any other operation performed by script is in execution? Is it safe playing around while I wait?

Theoretically, once you've selected the two folders as long as you don't perform file operations on either of the locations (or contents) it should be okay. And if you configure it to not display or save the report things will go a lot faster. I suppose I could add an additional option that would improve overall speed by sacrificing the formatting of the summary.

I've done the best I can using XY's scripting engine to ensure nothing goes terribly wrong, but it's ultimately the user's responsibility. (Don't make me put a disclaimer EULA and license on these scripts, at that point I'd just as soon quit contributing.)


However, this is the first I've noticed that XY no longer blocks during script execution.
Don, is this really desirable when quite a lot of the scripting engine relies on the current state of XY?

TheQwerty:

...within the confines of XY scripting it is going to take a while...

It took 28m54s to perform the task (thank you for adding so much info in the report!).
It seems to have zero impact on CPU performance, but I'd like to have the option to speed up stuff like that via script function or XY option. Does anyone knows of such thing?

@TheQwerty:
-I'm interested in the light version of the script, if you can provide it.
Will try to tweak and completely disable the report part for the times I don't need it. Seems not to be difficult (script stripped in sections = thanks!).
-any idea on how to fix the recursion problem in the original script, pointed by Don? I see use of such erasing capabilities, after playing with it a bit... but as it is, it's useless for huge amount of files (yet to zero in how much of them/error conditions).

All of the settings are stored at the bottom of the script file (hence why it must be run from a file).

Less clutter to deal with - just execute, save report (if any) and all done. Thank you!

Don't make me put a disclaimer...

Well... The only thing that users may be aware of is the time required to perform operations on several files and the need to put the script inside the <xyscripts> folder. Done.

Theoretically, once you've selected the two folders as long as you don't perform file operations on either of the locations (or contents) it should be okay.

Thanks for the info - it's very useful to have another opinion as this one will take a time to get stuff done and I've already have bad experiences with situations like that (scripts performing operations on the other pane as soon as it gets active).

Overall - thanks much for all effort, TheQwerty!

SkyFrontier wrote:It took 28m54s to perform the task (thank you for adding so much info in the report!).

I don't think there is any way for you to determine how long it took based on the summary, unless you know when it was started.

SkyFrontier wrote:... but I'd like to have the option to speed up stuff like that via script function or XY option. Does anyone knows of such thing?

Take the time (I know, I know) to learn how to program in a real programming language and I'm sure you can find a way to get better performance.

SkyFrontier wrote:-I'm interested in the light version of the script, if you can provide it.

For now disable all summary options in Config and that's the fastest you'll get. You will still get a final status message about the success/failure, but it won't tell you how many or what items failed.

Maybe later, I'll consider adding a don't format summary information option, which could trim it down a little more, but I doubt it'll get you much.

SkyFrontier wrote:-any idea on how to fix the recursion problem in the original script, pointed by Don?

Enable stepping mode and step through to find out what loop it is getting stuck in.

SkyFrontier wrote:Well... The only thing that users may be aware of is the time required to perform operations on several files and the need to put the script inside the <xyscripts> folder. Done.

Well I thought the fact that it was attached as a file, made it a bit obvious, but already done.. As for the speed, it takes as long as it takes.

TheQwerty:

I don't think there is any way for you to determine how long it took based on the summary, unless you know when it was started.

Yep, I did it.

Enable stepping mode and step through to find out what loop it is getting stuck in.

Thanks for the tip. Will try something later and publish a fix if something comes up to mind.

-Take the time (I know, I know) to learn how to program in a real programming language and I'm sure you can find a way to get better performance.
-Maybe later, I'll consider adding a don't format summary information option, which could trim it down a little more, but I doubt it'll get you much.

Well, I just can offer my stripped down version of the script for now (lol), also in hopes of offering you and community some benchmarking to work with if you really want to: it won't config anything, it won't pop reports therefore it will not tell if anything went wrong and where/how.
-but cataloging time (no reporting related activities) went down from 28m54s to 18m22s WITH last accessed info, 16m10s WITHOUT it (access dates seem to clone creation date except for the time, which is set to 00:00:00 - there were some unusual situations where the cloned files were displaying today as last accessed, 2 out of 92 in a test folder) but with statusbar and 8m52s (!!!) with no accessed info nor statusbar (I've read anywhere that this may slow down a bit, sorry - can't recall the reference). Well - almost 2/3 of gain on performance isn't that bad thing, huh?
For reference, test folder contains 2596 files in 105 folders.

Strangely, XY tree sometimes displays the newly created folder, sometimes not. Can't tell what produces the difference.

Thank you very much, TheQwerty!

Debugging the Mexican Deletion Tool (aka Recovering Deceiver, that's how I see that thing now...).
-it's impossible via the stepping method (unless I step through ~430 cycles of 6 or 7 OK'ing...)!
Stack size when the error occurs can be something like ~438. Any other hint?
Ah - this time XY crashed but politely popped an error screen on this XP SP3 machine (perhaps due to severe changes I made to software, now having temp .net vALL support): Suggestions:
-Stepping could have some sort of logging (it already allows copying of practically everything!);
-Steeping could have a mode to auto-execute a recursive command and halt when the next one "out of the recursion/cycle of stacking" is detected.

Thanks!