Scripting Bugs

Things you’d like to miss in the future...
TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Scripting Bugs

Post by TheQwerty »

Calling an XY menu via command ID may not reflect the current state of binary options.

For instance call the Show Items Menu via #490;.
Toggle a setting.
Call #490; again.
The Show Items Menu will continue to display the wrong state(s) until you open it via View->Show Items.

This is also an issue if you toggle one of those options directly via command ID.
For instance calling #496;#490; should toggle show folders and display the show items menu, but the menu is inaccurate until doing View->Show Items.

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

TheQwerty wrote:Calling an XY menu via command ID may not reflect the current state of binary options. ...
Yep, fixed. This has to be done case by case. I hope I got them all.

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Scripting Bugs

Post by TheQwerty »

admin wrote:
TheQwerty wrote:Calling an XY menu via command ID may not reflect the current state of binary options. ...
Yep, fixed. This has to be done case by case. I hope I got them all.
Fix confirmed! Not sure if I managed to check them all or not, but looks like you may have missed a couple..
#301; View->Views
#420; Tools->Customize List->Size Column Format

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

I have a script (see below) that is giving me problems.

Code: Select all

Set($cf,<curfolder>);
   Set($cp,<curpath>);
   Set($nn,<date yyyymmddhhnnss>);
   new "$nn-temp", dir;
   OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
   Msg("Press OK when WinRAR is finished.",1);
   GoTo("<curpath_s>\$nn-temp");
   Sel(a);
   Rename(b,$cf);
   Focus(L);
   MoveTo("..\..");
   #523;
   #523;
   Rename(b,$nn,"$cp");
   SelFilter($nn, d, Name);
   Focus(L);
   delete 1, 0, ;
There appears to be some timing issue once I click "OK", because instead of moving file(s) 2 levels up the file structure the whole shebang is shifted to RB. And if RB's allowed size is less that contents that have been deleted by this move then RB is bypassed and files are deleted without a confirmation dialogue :shock: I've lost about 8GB like that earlier today, so understandably I am not best pleased. From looking in RB, I know that Rename(b,$cf); happens correctly, but this script seems to ignore the rest until it comes to deletion. What could be going wrong here?

P.S. In step mode, the script works fine, which is why I believe that it is a matter of timing rather than anything else :?
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Scripting Bugs

Post by TheQwerty »

Well the OpenWith probably should have quotes around the "$nn-temp".

You don't mention how you have background processing/queuing setup so it's possible the script is proceeding without waiting for the move to finish.

The second Rename is using "$cp" as the preview argument, when I believe you meant it to be the item list.

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

TheQwerty wrote:You don't mention how you have background processing/queuing setup so it's possible the script is proceeding without waiting for the move to finish.
Both background processing and queuing are enabled.
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

nas8e9
Posts: 2232
Joined: 21 Jun 2008 14:50

Re: Scripting Bugs

Post by nas8e9 »

zer0 wrote:
TheQwerty wrote:You don't mention how you have background processing/queuing setup so it's possible the script is proceeding without waiting for the move to finish.
Both background processing and queuing are enabled.
It's possible to control background processing from a script:

Code: Select all

    v9.00.0021 - 2010-04-20 13:37
...
        + Scripting commands enhanced:
          - setting, settingp
            New named argument "backgroundfileops"
              0 = Disable background processing of file operations
              1 = Enable background processing of file operations
            Example:
              ::setting "backgroundfileops", 1;
...

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

nas8e9 wrote:It's possible to control background processing from a script:
Indeed, however those are intra-partition moves, so I don't need to get background processing involved as only changes to MFT are required. And regardless of background processing, in step mode the script works as intended :?
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

nas8e9
Posts: 2232
Joined: 21 Jun 2008 14:50

Re: Scripting Bugs

Post by nas8e9 »

zer0 wrote:Indeed, however those are intra-partition moves, so I don't need to get background processing involved as only changes to MFT are required. And regardless of background processing, in step mode the script works as intended :?
I may not have read too carefully. I did see the delete command in scripting causing problems, which reminded me of this thread in which TheQwerty had a major problem with deletes being handled in the background.

In general it might be an idea to retest with background operations turned off in the script (saving on hunt the setting :)). I don't know if this is a new script; did this use to work?

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Scripting Bugs

Post by TheQwerty »

zer0 wrote:
nas8e9 wrote:It's possible to control background processing from a script:
Indeed, however those are intra-partition moves, so I don't need to get background processing involved as only changes to MFT are required. And regardless of background processing, in step mode the script works as intended :?
Presumably in step mode you actually wait for it to finish the move before proceeding. Part of my question about background processing was the values in the File Ops->Apply To dialog, because for all we know you do have it set to do background processing of intra-volume moves as well.

nas8e9
Posts: 2232
Joined: 21 Jun 2008 14:50

Re: Scripting Bugs

Post by nas8e9 »

@zero: Completely OT, but...

Code: Select all

...
       OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
...
...are you aware that WinRAR has a 64-bit version that installs both a 32-bit as well as a 64-bit shell extension?

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

nas8e9 wrote:In general it might be an idea to retest with background operations turned off in the script (saving on hunt the setting :)). I don't know if this is a new script; did this use to work?
Yep, I will test when I get back home.
TheQwerty wrote:Presumably in step mode you actually wait for it to finish the move before proceeding. Part of my question about background processing was the values in the File Ops->Apply To dialog, because for all we know you do have it set to do background processing of intra-volume moves as well.
Hmm, interesting. A tweak that defaults intra-volume moves to use XYcopy was introduced about a week ago, which is around when I started having issues. Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default. I will test with it set at "7", but that's a bug either way.
nas8e9 wrote:@zero: Completely OT, but...

Code: Select all

...
       OpenWith("""C:\Program Files (x86)\WinRAR\WinRAR.exe"" e -- *.rar * $nn-temp", "s");
...
...are you aware that WinRAR has a 64-bit version that installs both a 32-bit as well as a 64-bit shell extension?
That's affirm. However, I seldom use WinRAR outside of XYplorer, so its 32-bit flavour is fine for me :)
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

TheQwerty
Posts: 4373
Joined: 03 Aug 2007 22:30

Re: Scripting Bugs

Post by TheQwerty »

zer0 wrote:Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default.
It should reflect that change on a fresh install. Upgrading should never change a user's settings to the defaults, so I don't think this is a bug.

zer0
Posts: 2673
Joined: 19 Jan 2009 20:11

Re: Scripting Bugs

Post by zer0 »

TheQwerty wrote:
zer0 wrote:Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default.
It should reflect that change on a fresh install. Upgrading should never change a user's settings to the defaults, so I don't think this is a bug.
While there's a debate to be had that whether an earlier, unchanged-by-user default should be overridden by a newer default, the fact that it does not do so isn't a bug in its "face value" sense, but may be an inconvenience (or more as I lost 10GB of data through this "inconvenience" :evil: ).

However, I will test using a modified tweak in a few hours and see how it works. There is a bug in there somewhere, it's just a matter of narrowing down where the cause lies. Will report what the tests show...
Reporting a bug? Have a wish? Got a question? Use search - View roadmap - FAQs: Forum + XY site
Windows 7/10
Always using the latest stable two-decimal build

admin
Site Admin
Posts: 60357
Joined: 22 May 2004 16:48
Location: Win8.1 @100%, Win10 @100%
Contact:

Re: Scripting Bugs

Post by admin »

zer0 wrote:
TheQwerty wrote:
zer0 wrote:Just checked the INI and a change from 14 to 7 for BackgroundedFileOps hasn't taken place -- presumably, it should have done as that's the new default.
It should reflect that change on a fresh install. Upgrading should never change a user's settings to the defaults, so I don't think this is a bug.
While there's a debate to be had that whether an earlier, unchanged-by-user default should be overridden by a newer default, the fact that it does not do so isn't a bug in its "face value" sense, but may be an inconvenience (or more as I lost 10GB of data through this "inconvenience" :evil: ).

However, I will test using a modified tweak in a few hours and see how it works. There is a bug in there somewhere, it's just a matter of narrowing down where the cause lies. Will report what the tests show...
Quoting the change log (watch the last line!):

Code: Select all

    * Background Processing: I now think that the factory default for 
      backgrounded file operations should NOT include intra-volume 
      moves. Backup will soon be added so this should already be 
      included. So the new default is:
         1 [x] Backup (currently unused; has yet to be coded)
         2 [x] Copy
         4 [x] Cross-volume move
         8 [ ] Intra-volume move  (always parallel = not queued!)
        16 [ ] Delete             (always parallel = not queued!)
      The default value is 7 (1+2+4):
        BackgroundedFileOps=7
      This will not affect your configuration when you upgrade.

Post Reply