Time stamps

[ryanb1]

HI,

I have setup VV and VVengine and everything seemed to work on the test folders i tried.

Saved the profile and ran the initial copy on the source and target that i am using but all of the copied files date modified change to the time of copy.

Not sure why as the initial test copy worked.

I have "retain folder created and modified" ticked.

Any ideas would be helpful!

Cheers
Ryan

[TGRMN Software]

Hi, are ViceVersa and VVEngine running under different accounts ? Were the timestamps OK when running in ViceVersa but not OK when running un VVEngine? thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[ryanb1]

No same account.

It was the original copy in ViceVersa from Source to Target folders. All had the copy timestamp rather than retaining the original

[TGRMN Software]

Can you try again in the same manner as you did the initial copy? thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[User]

I have been using VV Pro for many years and it has never fixed the time stamp problem. When you set the "Retain folder and modified timestamps when copying" button, VV only retains the modified timestamp for the destination file. The create timestamp for all files and folders will always be the date that VV first copied the file to the destination disk.

The date that shows up in windows file manager is the modified date. But if you look at the properties of the file in the destination disk, you will see that the create date is not the one from the source, it is the date that VV first copied the file to the destination.

This creates a mess because the next time you do a backup with that profile, VV will say most of the destination files are newer than the source files, except the ones that have truly been changed since the last backup.

So basically, the program backs up correctly and your files are safe, but the creation dates for files and directories in the destination will be all out of wack, and the source-destination comparison window when you run VV will be a total mess.

[User]

I have to revise my last post. The process of writing the last post made me want to look into it again, because it has been a pain in the a real annoyance for many years.

It looks like VV is actually doing it correctly. I recently upgraded our 5TB backup disk to an 8 TB backup disk because we were running out of space. I did a backup to the new disk yesterday, 800,000 files in 69,000 directories. And, I saw that all of the modify dates were correct, but the creation dates were wrong.

Typically the first thing that I do is copy all of the files over to the new backup disk using windows. Then I use VV to keep the backup disk up to date. The problem is that during that first copy, Windows changed all of the destination file and directory creation dates to the date that the copy took place even though the modify date may be years ago. Windows did preserve the modify date. Now when I run VV, it thinks that all of the destination files are newer than the source files.

I performed a test, and the way to avoid this is to manually create the upper most directorie(s) on the destination disk (or destination location), and then let VV do all of the first copies over to those upper most directorie(s). VV, unlike Windows copy, will preserve the creation date and modify date. Then let VV keep the disk up to date.

I tested this on a few directories and all the creation dates matched the source, except of course for the upper most directory that I had to create so the VV profile could synch. The key here is to never use windows to copy files over to a destination directory that you are using to synch with VV. Use VV for the first copy and all subsequent sync's.

Now I just have to recopy 800,000 files over twice to the two separate 8TB backup disks. That's going to take a full day.

[User]

Well I have to take back my revision to my original post. I ran a test on a small subset of files and the original file creation date was maintained. But when I did a backup of the all 4 directories with around 800,000 files, about half of the files retained the original creation data, and the other half had their creation dates changed to the date that the VV backup was run.

So, I tried another test. I erased several files on the destination drive that had their creation dates changed by VV and reran VV, thinking that maybe the problem only exists when you have a lot of files in the backup. But the 4 files that I erased, which have 9/19/2009 creation dates in the source, ended up with 4/24/2016 creation dates after I did a backup with VV.

I give up. I have been seeing this problem for the last 6 or 7 years and I don't think it is ever going to be fixed.

[TGRMN Software]

Hi , this is strange, which ViceVersa PRO version / build are you using?
What hardware is the target? Try copying files to a different drive with ViceVersa or a different folder on same disk for a test. While Windows does not maintain the "created" timestamp when copying files, ViceVersa should by default (hardware permitting).

thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

[Kritiker]

I too am seeing this problem with VV Pro 2.5 Build 2518 & VVEngine 2.1 Build 2106 in doing the initial backup in Windows 7 Pro 64 bit..

[TGRMN Software]

Hi, is it a problem with the "creation date" of files copied by ViceVersa not being maintained? What systems /hardware are source and target? thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com