XYplorer Beta Club

I started to write up a bug with XYcopy and in testing to write it up, I think I experienced a couple other bugs.

Bug 1: This seems to only happen when using XYcopy to move (not copy) a folder (which already exists) to a network location. I cannot reproduce this when moving to another local drive. When overwriting the existing folder on the network drive, the tags from the local drive are not copied/overwritten on the network drive.

Bug 2: During a couple test moves, an older set of tags (used when moving an earlier test, but not yet saved to tags.dat) was written to the network drive instead of the current source folder tags.

Bug 3: On several of my move tests, I failed to get an overwrite prompt, the move just took place without prompting to overwrite. This seems somewhat random, I cannot reliably reproduce, but it happened a few times.

Bug 4: Always Show Folder sizes is checked in configuration, "except in network locations" is also checked. The pane with the network folder location does have the size column, and the view is saved, but the global setting should be directing XY to not show folder sizes. When I was testing/documenting to write up the original problem, that pane began collecting folder sizes, with "press esc to stop" in the status bar. This view should not be showing folder sizes.

To summarize: XYcopy seems to be working pretty reliably when copying or moving between local drives, but at least for me, exhibited a number of apparent bugs when copying/moving/overwriting an existing target folder on a network drive.

lol, I just hit "remove all tags" in each of several columns, repeatedly, and instead of removing them, it actually crawled up the z-order, like "undo", and replaced with the previous tags, not once, not twice, not three times, but 5 times up the stack. Again, this was in the network folder. Sorry to laugh but that was kind of funny.

These are many different observations. Just to make sure we are talking about the right thing: XYcopy is NOT Custom Copy, but is a separate module that handles background file operations. So, are we talking about Custom Copy or about background file operations?

the built-in handler (XYCopy) for background operations. Using any other handler would ignore tags altogether, right?

After updating to 23.30.0101, I just reproduced this again, only this time in both directions:

In the below, "S:" is a mapped network drive, and "D:" is a local drive:

1. Copied folder from S: to D:, no bug.
2. Modified Comment and Tags column, Moved from D: back to S:, overwrite prompt correctly given, no bug (updated tags correctly)
3. Exited without saving (although Tags are set to save instantly, so those are expected to be persisted)
4. restarted XY, chosen tabs not saved (this is correct), tags saved (this is also correct given my configuration)
5. Copied again from S: to D:, bug this time the OLD tag was placed on D: while the new tag remained on S:
6. Copied again now back from D: to S: (overwrite prompt received) and the incorrect tags from D: were not written back to S: (no bug, but strange anyway, since D wrongly showed the OLD tags)

Another new bug:

I just did "Ctrl+Z" to undo the move/overwrite from D: to S: but instead of moving the folder back to D: and leaving the copied folder on S:, the undo actually just moved the folder back to D: this is a bug since the last operation was to move/overwrite, but undoing it moved the folder back instead of leaving the original in place

NB: I have all these weird copy/move/overwrite cases because I do a lot of music editing, but doing so on the network folder is slow, so I move the folder to the local drive, make my edits, then move it back to the network once completed and tagged. Sometimes, a folder will still exist on the network and this is how I first observed these issues.

XYCopy is totally unrelated to tags. It doesn't even know that tags exist and it doesn't care. Don't you see the same issues when copying files in the foreground?

Sorry, yes, I misspoke, I am seeing the copy progress dialog, including the overwrite prompt (except a couple times there was no overwrite prompt), so I am not referring to background processing.

Is this ticked: Configuration | Information | Tags | Copy tags on copy operations?

Yes, both copy tag options are checked - if not, then I'd never have them copied, what I am seeing is sometimes when a target folder exists, the tags are not copied correctly.

Checked Bug 1: Cannot confirm.

Your tags DB might be corrupt. Please run a full Database Check (incl. Dupe Removal) from Configuration | Information | Tags | Options...