XYcopy wishes

[nas8e9]

...

I have to add that while working with the shell API only (= XYcopy 1.0) I can add a verification only for COPY jobs, because after a MOVE there's nothing left to compare.

Perhaps that's why some other programs use a hash function for verification: they hash the files to be moved beforehand, perform the move (leaving no source files) and then hash the moved files again to compare against the hashes of the source files. For XYcopy 2.0, it seems much more robust to perform a copy (leaving both source as well as destination files) first, then comparing source and destination before, after successful verification, removing the source files.

[RalphM]

For XYcopy 2.0, it seems much more robust to perform a copy (leaving both source as well as destination files) first, then comparing source and destination before, after successful verification, removing the source files.

Which means performing a copy, even if the file is moved on the same drive - probably not the best approach for bigger files in this situation, me thinks...

[nas8e9]

For XYcopy 2.0, it seems much more robust to perform a copy (leaving both source as well as destination files) first, then comparing source and destination before, after successful verification, removing the source files.

Which means performing a copy, even if the file is moved on the same drive - probably not the best approach for bigger files in this situation, me thinks...

XYcopy 1.0 currently already excludes file moves within the same drive from autoqueuing since it merely involves Windows updating the MFT instead of actual file reading/writing. There is obviously a performance trade-off with verification, but for certain kinds of file operations (particularly over a wireless network) it is a relevant function.

[admin]

...

I have to add that while working with the shell API only (= XYcopy 1.0) I can add a verification only for COPY jobs, because after a MOVE there's nothing left to compare.

Perhaps that's why some other programs use a hash function for verification: they hash the files to be moved beforehand, perform the move (leaving no source files) and then hash the moved files again to compare against the hashes of the source files. For XYcopy 2.0, it seems much more robust to perform a copy (leaving both source as well as destination files) first, then comparing source and destination before, after successful verification, removing the source files.

Yes, that would be a reason to use hashes. And I agree with your idea for XYcopy 2.0.

Actually, because I don't have a good answer to the question "Why verification only for Copy and not for Move?", I decided to leave verification for XYcopy 2.0. It just fits better in there. I then can do the verification even file by file (and ask whether to continue after the first problem). So a move would be
- copy file 1 -- verify -- delete source 1
- copy file 2 -- verify -- delete source 2
- etc.

[nas8e9]

...

I have to add that while working with the shell API only (= XYcopy 1.0) I can add a verification only for COPY jobs, because after a MOVE there's nothing left to compare.

Perhaps that's why some other programs use a hash function for verification: they hash the files to be moved beforehand, perform the move (leaving no source files) and then hash the moved files again to compare against the hashes of the source files. For XYcopy 2.0, it seems much more robust to perform a copy (leaving both source as well as destination files) first, then comparing source and destination before, after successful verification, removing the source files.

Yes, that would be a reason to use hashes. And I agree with your idea for XYcopy 2.0.

Actually, because I don't have a good answer to the question "Why verification only for Copy and not for Move?", I decided to leave verification for XYcopy 2.0. It just fits better in there. I then can do the verification even file by file (and ask whether to continue after the first problem). So a move would be
- copy file 1 -- verify -- delete source 1
- copy file 2 -- verify -- delete source 2
- etc.

I can see why you'd move verification to XYcopy 2.0: it would be incomplete when relying on the shell functions. Having said that, I'd have use for verification just for the copy function.

XYcopy 2.0 in general is, well, tantalizing...

[zer0]

Actually, because I don't have a good answer to the question "Why verification only for Copy and not for Move?", I decided to leave verification for XYcopy 2.0. It just fits better in there. I then can do the verification even file by file (and ask whether to continue after the first problem). So a move would be
- copy file 1 -- verify -- delete source 1
- copy file 2 -- verify -- delete source 2
- etc.

This is something I would like as well, not on a file-by-file basis though, but on a batch basis. What I like about how you described that "move" is that it has the safety of a copy combined with a convenience of deletion being done at the end. When transferring large volumes of data (dozens of Gb) between partitions, I always opt for "copy, check all is well and then delete" approach rather than "move". Had some bad experiences in the past when moving files, so once bitten twice shy...

[admin]

Actually, because I don't have a good answer to the question "Why verification only for Copy and not for Move?", I decided to leave verification for XYcopy 2.0. It just fits better in there. I then can do the verification even file by file (and ask whether to continue after the first problem). So a move would be
- copy file 1 -- verify -- delete source 1
- copy file 2 -- verify -- delete source 2
- etc.

This is something I would like as well, not on a file-by-file basis though, but on a batch basis. What I like about how you described that "move" is that it has the safety of a copy combined with a convenience of deletion being done at the end. When transferring large volumes of data (dozens of Gb) between partitions, I always opt for "copy, check all is well and then delete" approach rather than "move". Had some bad experiences in the past when moving files, so once bitten twice shy...

All cross-volume moves are internally copy+delete. Bytes cannot be "moved".

[ghost zero]

i would like to see file sizes of the operations in the background jobs window

[admin]

i would like to see file sizes of the operations in the background jobs window

Will come with XYcopy 2.0.

[zer0]

Actually, because I don't have a good answer to the question "Why verification only for Copy and not for Move?", I decided to leave verification for XYcopy 2.0. It just fits better in there. I then can do the verification even file by file (and ask whether to continue after the first problem). So a move would be
- copy file 1 -- verify -- delete source 1
- copy file 2 -- verify -- delete source 2
- etc.

This is something I would like as well, not on a file-by-file basis though, but on a batch basis. What I like about how you described that "move" is that it has the safety of a copy combined with a convenience of deletion being done at the end. When transferring large volumes of data (dozens of Gb) between partitions, I always opt for "copy, check all is well and then delete" approach rather than "move". Had some bad experiences in the past when moving files, so once bitten twice shy...

All cross-volume moves are internally copy+delete. Bytes cannot be "moved".

That's why I put move in quotes From a user perspective, it's movement, but under the bonnet it's copy+delete. What I would like is copy+check+delete. The check part doesn't have to be fancy -- count of files "moved" and file size match should suffice for the time being. It's all about inspiring more confidence in the move operating and not potentially suffering data loss while making the process more automated.