Custom Copy changes the date created and date modified when it shouldn't

[Kyle]

After certain operations, Custom Copy updates the dates on files and folders when it shouldn't have, based on the behavior of the native implementation of copy and move in Windows. I've attached a table highlighting the differences I found. I'm running XYplorer 23.10 on Windows 11, and using only NTFS volumes, and I have secure overwrite enabled and preserve dates disabled. Enabling preserve dates does not address this issue, because it creates a different set of inconsistencies with the way Windows does things.

Here's my summary. Folder merges retain the date created from the receiving folder, but the date modified is updated when the contents change. I didn't notice any problem with that case in Custom Copy, so I didn't include folder collisions in the table. For the rest, including operations with files and folders done within a parent folder as part of a merge of the parent:

• When you move a file or folder, Custom Copy should not change either date, even if you moved to another volume
• When you make a copy of a folder, Custom Copy should not update the modified date on the copy or its children
• When you copy over a file on another volume, Custom Copy should carry over the date created from the replaced file

I think it's important for Custom Copy to be consistent with the native implementation on these details in its default configuration because the way users reason about file dates is informed by the native implementation. Date modified is "the time when the contents of this file or folder last changed", and date created is "the time when this file or folder was first stored on this PC" (or when you made the copy, for a copy).

[admin]

If preserve dates is disabled, then XY does not care about the dates, and Windows is responsible for the results you get.

[Kyle]

Understood. It's more accurate to say that Custom Copy hasn't been designed to match this aspect of native behavior. To match the native copy and move, it would be necessary for Custom Copy to change the dates in some cases.

For example: to implement a cross-volume move you must create the files on the new volume. To match the native behavior, you would need to change the date created back to what it was on the previous volume. From the user's point of view, it should look like the date created hasn't changed. Another example: the date modified on a copy of a folder is updated by the filesystem as things are copied into it. You would need to change that date back to what it was on the original folder in order to match the native behavior.

[admin]

For example: to implement a cross-volume move you must create the files on the new volume. To match the native behavior, you would need to change the date created back to what it was on the previous volume. From the user's point of view, it should look like the date created hasn't changed.

Indeed, I can confirm this for Win 8.1. I wasn't aware of this, or did it change since Windows XP (which is probably when I checked it the last time)? Anyway, I will change this. Thanks!

Another example: the date modified on a copy of a folder is updated by the filesystem as things are copied into it. You would need to change that date back to what it was on the original folder in order to match the native behavior.

This one I cannot confirm for Win 8.1. Here the date modified on a copy of a folder is always updated to "now" by the filesystem.

[Kyle]

In an effort to make testing easier and more consistent, I wrote a script to automate the file operations and draw up a report. The script uses Pane 1 as the source folder and Pane 2 as the target folder. Custom Copy is tested automatically but you would still need to direct the shell to resolve a few conflicts by replacing or renaming.

I don't have Windows 8.1 but I was able to test with Windows 7, which was consistent with Windows 11 in the shell implementation but had a difference with Custom Copy for cross-volume replace. I was also able to test operations to and from the network, which I found were similar to cross-volume. I've attached the script and a copy of my results on Windows 7 and 11.

Edit: re-uploaded my tests after running them in 23.10.0004

[admin]

Wow, 5-start report!

Is it correct that your script only tests empty folders? I think it makes a difference when there are files in them. It's the copying of the contained items that updates a folder's modified date to now.

[Kyle]

Indeed! My script tests with empty folders, and it's only empty folders that keep the modified date from before the copy. What confused me is that shell copy is using lazy writes. So the modified date on a copy of a folder starts out the same as the original folder, but changes to the time the folder was copied only after you wait some time or visit the folder and force its contents to be written. Of course I don't expect Custom Copy to replicate this behavior.

Then unless I've missed something, the only remaining differences are modified date for copies of empty folders and created date for copies of files that replace files on another volume.

[Horst]

Indeed! My script tests with empty folders, and it's only empty folders that keep the modified date from before the copy. What confused me is that shell copy is using lazy writes. So the modified date on a copy of a folder starts out the same as the original folder, but changes to the time the folder was copied only after you wait some time or visit the folder and force its contents to be written. Of course I don't expect Custom Copy to replicate this behavior.

Then unless I've missed something, the only remaining differences are modified date for copies of empty folders and created date for copies of files that replace files on another volume.

Its a normal Windows function and behaviour.
Whenever you update files in a folder the folder time stamp is updated.

[admin]

... and created date for copies of files that replace files on another volume.

As I said, I think this is a bug. Why only cross-volume? Why only copies (not moves)? Doesn't make sense. Smells like a Windows 11 bug.

[Kyle]

As I said, I think this is a bug. Why only cross-volume? Why only copies (not moves)? Doesn't make sense. Smells like a Windows 11 bug.

I found that Custom Copy has different results for Windows 7 and Windows 11 in this particular case. So it could be a bug or a change in Windows 11 that impacts Custom Copy. However, the behavior of shell copy remains the same on either OS, and it's consistent with intra-volume and network copies too. With shell copy, copying a file over another file always carries over the created date of the file you are replacing (it's as if you opened the existing file and changed its contents).

Its a normal Windows function and behaviour.
Whenever you update files in a folder the folder time stamp is updated.

Yeah. This is what I expected to see, but the lazy writes surprised me. Even refreshing the folder view does not make the timestamps update, you have to actually visit the folder. I should have looked at it more closely instead of adapting my reasoning to a conclusion not based in reality.

[admin]

Here in Win 8.1 XYplorer behaves exactly as File Explorer:

Code: Select all

intra-volume replace file, dates in target file:

       modified    created
copy   of source   of target
move   of source   of source

[Kyle]

Yeah, on Windows 11 both intra-volume and over the network copy & replace are working as expected. Moves are also working as expected. It's just cross-volume copy & replace that's off. When I try it on Windows 11 I get this:

Code: Select all

cross-volume replace file, dates in target file:

       modified    created
copy   of source   now       (Custom Copy)
copy   of source   of target (Shell Copy)

I doubt many people would notice this little detail. It certainly won't stop me from using Custom Copy but I thought I'd mention it for the sake of completeness.

Also, there's a regression in 23.10.0008 with created date on empty folder copies. Only the modified date should be carried over from the source, created date should be now.

[admin]

In Win 8.1 it's both identical:

Code: Select all

cross-volume replace file, dates in target file:

       modified    created
copy   of source   of target (Custom Copy)
copy   of source   of target (Shell Copy)

Fixed the regression with folders.

Looks good now:

2022-05-28_094335.png (19.56 KiB) Viewed 5554 times

2022-05-28_124607.png (19.33 KiB) Viewed 5545 times

[Philip09621]

You know, Windows usually updates the "Modified" date whenever you save a file, which can be a bit annoying if you just made a small change and wanted to keep the original date. Unfortunately, there's no built-in Windows setting to directly prevent this from happening with regular edits.
However, there are a couple of workarounds you could try if you really need to keep that original date:
One way is to make a copy of the file, edit the copy, and then delete the original. The copy will have the new modified date, but your original will remain untouched. It's not ideal if you're constantly making small tweaks, but it works in a pinch.
Another approach, if you're comfortable with it, is to use the Command Prompt with the copy command. If you use the /B switch (for binary copy) and add +,, after the source filename, it can sometimes preserve the original modified date. For example, if your file is named "my_document.txt", you'd type something like copy /b my_document.txt+,, my_document.txt and press Enter. Be super careful with this command though, as it overwrites the original file! Make a backup first, just in case.

If you are facing the issue after trying these solutions, you can follow for more details instruction below.
https://thegeekpage.com/how-to-edit-fil ... ows-10-11/

[phred]

One way is to make a copy of the file, edit the copy, and then delete the original. The copy will have the new modified date, but your original will remain untouched. It's not ideal if you're constantly making small tweaks, but it works in a pinch.

Perhaps it's me, but this statement makes no sense.
1- You say make a copy, edit, and then delete the original. But then you say the original will remain untouched. How does this help keep the date when suggesting to delete the original?

2- It's much easier to select the file(s) in XY and show the Properties tab in the Info Panel. You can then change any or all of the Created, Modified, or Accessed dates and you're done.