Copy file does not retain modified timestamp

[greymont]

I have upgraded from BC 3 to BC Version 4.0 beta (build 18291).

Now in folder compare view when I copy files the new files do not get the same modified timestamp as the original. They all get a timestamp as of when the copy was performed. This is new to me. I've searched for where to configure this but cannot find anywhere. How can I restore the previous behaviour?

[greymont]

OK, I think I found the answer. I checked off "Copy creation dates" in the Handling tab of the Rules dialog.

I was confused by this choice since I was looking for something like "update modified date", not "update creation date". Are they really the same thing? I thought NTFS maintained creation date separate from modified date and displayed modified date in the directory listings.

Anyway, I think this does what I want. I will just watch it closely.

[Aaron]

Hello,

That option should only cover the Creation Date timestamp, and not effect the Last Modified timestamp. Some devices/destinations do not support preserving the Last Modified timestamp, but that does not sound like what you are running into. What type of destination device are you copying to?

Update: And which OS are you running BC4 beta on, and the source side?

[mvanbibber]

Hello,

That option should only cover the Creation Date timestamp, and not effect the Last Modified timestamp. Some devices/destinations do not support preserving the Last Modified timestamp, but that does not sound like what you are running into. What type of destination device are you copying to?

Update: And which OS are you running BC4 beta on, and the source side?

Did you guys get this figured out? I need the folder time stamps to be retained. If I use robocopy it saves the time stamps on folders including the modify date.

If I use BC4 from the same machine it does not retain the modify date. I was going to use the BC4 but if it cannot copy the modify date then I can't use it. I do see that if I copy a folder and it is empty that it retains the modify date, not sure what the difference is. Hope you guys reply back quickly :-)

Thanks,
Matthew A. Van Bibber

[Chris]

Matthew,

Beyond Compare 4 will preserve file modified dates. It does not preserve folder modified dates when copying files.

After a copy, you can try copying folder dates using the "Actions > Touch" command. Copying folder dates with the touch command should work if your file system is NTFS, if you're copying to a fat32 file system or a non-Windows network drive then it might not be supported.

[jof]

I have upgraded from BC 3 to BC Version 4.0 beta (build 18291).
Now in folder compare view when I copy files the new files do not get the same modified timestamp as the original.

Does this still happen? Is it a bug?

It does not preserve folder modified dates when copying files.
After a copy, you can try copying folder dates using the "Actions > Touch" command.

Could we have this as an option please?
It should be as simple as this - after a file copy, copy the timestamps for its parent folder from source to destination.
Depending on how structured your file copying is, it could be done once after all file copies in the folder have been completed.

If a large copy/sync operation is being performed, manually touching each folder when there could be hundreds or thousands is not an option. That's what software is for.

Basically, I would like BC to create an almost identical copy on the destination - files and folders including all timestamps and attributes (wherever possible).

[Aaron]

Hello,

As Chris mentioned, if a file does not preserve the last modified date, this is generally under control of the destination device. We try to preserve it during the copy, but some destinations do not allow it. Please try the same copy with the same file pair using Windows Explorer to verify. The Touch command can sometimes work around this, as it can sometimes set the date where the copy cannot.

It is on our wishlist to add options to preserve Folder timestamps. However, many functions in the OS will often update the timestamp of folders. For example, we actually do preserve the timestamp initially, but as soon as files are copied into the folder the timestamp is updated by the OS. This is the same behavior as Windows Explorer.

[jadik]

Mac: preserve folder timestamp fail during mirror: possible approach offered

Sadly, I was unable to find any facility or integrated function that even attempted to preserve folder timestamp attributes on the Mac version, while using the latest published build: Beyond Compare Pro Version 4.0 (build 18847).

While the file timestamps were cleanly copied, the folder timestamp attributes were not. Since this was a showstopper for me, (migrating my work files to a new MacBook, and depend on having accurate timestamps for BOTH folders and files), I needed to find a solution. Fortunately, using Mac terminal I engaged the rsync -a <source> <target> command and was able to quickly resolve the problems. Perhaps you could employ this strategy, or something similar, within the programmatic backend of the BC application?

Thank you for all your hard work on this app... having a native Mac Port of this tool I have long loved on Windows, is truly appreciated & applauded!

[Aaron]

Thanks!

As Chris mentions a bit earlier, our timestamp preservation is centered around the file level. The folder modified timestamps are not preserved during a copy because we are mirroring the logic used by the system Copy command. If you were to perform the same copy in Finder, I expect you would see the same behavior. Technically, the folder timestamp is preserved, but as soon as any interaction is done with the folder (copying in additional files), it is immediately updated.

It is on our wishlist to expand this behavior and offer options to try and preserve the modified timestamp of folders. Please be aware that many day to day actions (independent of Beyond Compare) can trigger the OS to update the folder timestamp; we've found they aren't terribly reliable and hence why we display them but don't compare them (and instead compare the files within).