XYplorer Beta Club

I have noticed an issue since recent XYcopy changes, now if I have a file open in an app that locks it and I try and move it I get no error msg/try again dialog, and the status bar says "all background jobs completed", previously I would get a "The action couldn't be completed because the file is open in "Whatever App", Close the file and try again." It is very easy to miss that the file wasn't moved now, for example if you select 4 files and only 1 is locked it moves 3 files and says job completed, but the fourth file stays put.


My relevant settings are as below, (using fresh with CC disabled shows the expected dialog) currently using v22.50.0108:

jupe wrote: ↑29 Nov 2021 03:56 It is very easy to miss that the file wasn't moved now, for example if you select 4 files and only 1 is locked it moves 3 files and says job completed, but the fourth file stays put.

+1
A safety belt would be good here.
XYplorer could check before start copying if one of the selected files is locked and ask what to do.
(But it is more for "Wishes"?)

Could you also show these settings:

I am 95% sure I haven't changed any of them from the default, can't upload screenshot until tomorrow, not near computer currently.

FYI I did try using new XYcopy with old ver of XY and that produced a different dialog than normal, it was the XYcopy move failed text box dialog, forgot to see if a normal transfer would have worked though. Doh!

OK, that's enough to know, thanks.

I don't think this is a new problem. Did not test an older version yet, but I see no connection to the recent XYcopy changes.

Well it's only happened within the last week, so I assumed XYcopy changes, some other recent change may be the cause. Tomorrow I will try using new XY old XYcopy (opposite to what I already tried) and see what happens.

You are right, something changed.

OK, what happened is this: Before 20211127, if Configuration | File Operations | File Operations | Custom Copy Operations | No progress dialog on intra-volume moves was ticked, intra-volume moves were actually *never* backgrounded but run immediately in the foreground regardless of the settings in Configuration | File Operations | File Operations | Background Processing | Apply to.... On 20211127 I changed that to work as advertised, so intra-volume moves *are* backgrounded now if you want them to. This again led to insufficient feedback in the status bar, which will be improved in the next beta.

I tried the new version and have some observations, now a status bar msg (which would be very easy to miss) appears instead of the shell style dialog, so to avoid getting only a status msg, which has no offending filename shown, I try un-ticking move from intra-volume in the Apply To dialog, this produces a dialog, but its the custom copy failed text box dialog, which is lacking a try again button like the original shell dialog, and also doesn't tell you the filename of the failed file, just the to/from paths so I have to track down the failed file now (which could be part of a large group), instead of just being able to unlock the file and press try again.

If you are not seeing this you probably should set "On failures" to "Ask" in Configuration | File Operations | File Operations | Custom Copy Operations | Configure....

Ok, since the changes were undoc'd, I didn't think I would need to change that setting to get behavior I had always had, anyway that seems to be working as desired so far, thanks.