Exit XYcopy upon close of XYplorer

[nas8e9]

OK, so we the last couple of betas I started noticing that XYcopy.exe began being orphaned again. As seen in the screenshot below, XYcopy.exe is still running despite no active background processing.

xycopy_orphant.PNG

Copy handler in question is v1.00.0031

Looking back, does the following still apply:
- no error messages from either XYplorer or Windows;
- all file operations you initiate are indeed carried out?

Also, are one or more file operations script-initiated and/or with a network destination, when stray XYcopy.exe-instances crop up?

[zer0]

Looking back, does the following still apply:
- no error messages from either XYplorer or Windows;
- all file operations you initiate are indeed carried out?

Both still apply.

Also, are one or more file operations script-initiated and/or with a network destination, when stray XYcopy.exe-instances crop up?

None are script-initiated. Destinations for jobs were DAS and a USB-connected external HDD.

[nas8e9]

Looking back, does the following still apply:
- no error messages from either XYplorer or Windows;
- all file operations you initiate are indeed carried out?

Both still apply.

Also, are one or more file operations script-initiated and/or with a network destination, when stray XYcopy.exe-instances crop up?

None are script-initiated. Destinations for jobs were DAS and a USB-connected external HDD.

Do you have both Background processing as well as Queue file operations enabled, with the former applied to all operations?

If so, it becomes the question which kind of XYcopy.exe-instance becomes stuck. AFAIK, if the queue is enabled, one (queue)instance handles all queued file operations while intra-volume moves as well as deletes (if those are configured as background operations), are handled in parallel by additional instances. Do you mix copy and inter-volume moves with deletes and/or intra-volume moves when a XYcopy.exe-instance becomes stuck?

Also, do you ever see more than one XYcopy.exe-instance dormant?

Finally and just to confirm, once there's a dormant instance, does initiating a new backgrounded file operation spawn a new XYcopy.exe instance which does terminate once it's done its job?

Edited to add: In order to further exclude the obvious, what security software do you use and are XYplorer.exe and XYcopy.exe excluded from real-time scanning?

[zer0]

Do you have both Background processing as well as Queue file operations enabled, with the former applied to all operations?

Yes.

Do you mix copy and inter-volume moves with deletes and/or intra-volume moves when a XYcopy.exe-instance becomes stuck?

All ops in the current session were between different volumes. That's the only situation when I have XYcopy get involved.

Also, do you ever see more than one XYcopy.exe-instance dormant?

No.

Finally and just to confirm, once there's a dormant instance, does initiating a new backgrounded file operation spawn a new XYcopy.exe instance which does terminate once it's done its job?

Yes.

Edited to add: In order to further exclude the obvious, what security software do you use and are XYplorer.exe and XYcopy.exe excluded from real-time scanning?

Norton Internet Security 2011. Yes, both are excluded.

[nas8e9]

Thank you for the info. No obvious clues, unfortunately.

Again going back in this thread, the big problem is determining whether this only happens with your specific configuration and/or usage, or whether other users are affected. This bug is so benign (no error messages, no failed operations), non-obvious (only people with Task Manager or Process Explorer need apply) and so far impossible to reproduce reliably, that it's both almost unnoticeable (save for when updating XYplorer, of course) and unactionable.

One last question: you mentioned that you hadn't seen this problem in a while. Can you pinpoint with which versions this problem stopped and started again?

[zer0]

Can you pinpoint with which versions this problem stopped and started again?

If memory serves, it started with one of the betas at the end of the .0700 cycle (I have 701, 707 and 710) and once I have updated to build 803.

[nas8e9]

Can you pinpoint with which versions this problem stopped and started again?

If memory serves, it started with one of the betas at the end of the .0700 cycle (I have 701, 707 and 710) and once I have updated to build 803.

The sole reference in the beta changelog that's directly to do with background processing is for 9.90.803, by which time the problem had already reappeared:

Code: Select all

    v9.90.0803 - 2011-04-17 20:44
        + Tweak to allow backgrounding file operations that were initiated
          by drag'n'drop from outside (= from another app into XYplorer).
            BJAllowDropFromOutside=1

Again, no clues.

[admin]

Can you pinpoint with which versions this problem stopped and started again?

If memory serves, it started with one of the betas at the end of the .0700 cycle (I have 701, 707 and 710) and once I have updated to build 803.

The sole reference in the beta changelog that's directly to do with background processing is for 9.90.803, by which time the problem had already reappeared:

Code: Select all

    v9.90.0803 - 2011-04-17 20:44
        + Tweak to allow backgrounding file operations that were initiated
          by drag'n'drop from outside (= from another app into XYplorer).
            BJAllowDropFromOutside=1

Again, no clues.

That's true, nothing else has been changed concerning this.

[zer0]

That's true, nothing else has been changed concerning this.

Technically, nothing had to change. Whatever permutation of factors that cause this process to become an orphant may have stopped happening for a while. One of those factors has to be XYplorer as it is in charge of its child processes. I see no harm in adding a tweak that makes XYplorer check if XYcopy is running prior to closing it. My main reason for closing XY is to update it to a newer version and an orphaned XYcopy.exe prevents that from happening smoothly.

[admin]

That's true, nothing else has been changed concerning this.

Technically, nothing had to change. Whatever permutation of factors that cause this process to become an orphant may have stopped happening for a while. One of those factors has to be XYplorer as it is in charge of its child processes. I see no harm in adding a tweak that makes XYplorer check if XYcopy is running prior to closing it. My main reason for closing XY is to update it to a newer version and an orphaned XYcopy.exe prevents that from happening smoothly.

I'd rather understand what's going on. One day I will be able to reproduce it.

[zer0]

I'd rather understand what's going on. One day I will be able to reproduce it.

That makes two of us. However, as I cannot pin it down, I hope you have better luck in isolating this unicorn of a bug.