Filestamps appear to be rounded down to the nearest second

Guest

I am using 64 bit build 2513 of vice versa pro to synchronise drives. I now see that modified dates are not copied exactly. They are all rounded down to the nearest second.
If I use windows copy instead, then the millisecond portion of the timestamp is copied correctly.

I am consolidating several million files onto larger raid 5 GPT arrays and thousands are failing their QA test with timestamp differences of 2 seconds.

My profile does not have the ignore 2 second flag set. When comparing 2 drives containing files with timestamp differences of less than 1 second no differences are shown.

Is this a feature or a bug? Is there a setting I have missed that will allow the modified timestamp to be copied exactly?

Regards
Andy
Running on Windows 8.1

akeogh · Joined: 08 Jan 2011 Posts: 3

TGRMN Software · Site Admin Joined: 10 Jan 2005 Posts: 8769

What file system is on the target drive? FAT, (V)FAT and FAT(32) maintain a file's timestamp to an accuracy of two seconds whereas NTFS is accurate to the millisecond. When files are copied from an NTFS drive to a FAT drive the timestamps can change by up to 2 seconds but the files remain the same.

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

akeogh · Joined: 08 Jan 2011 Posts: 3

Q What file system is on the target drive? FAT, (V)FAT and FAT(32) maintain a file's timestamp to an accuracy of two seconds whereas NTFS is accurate to the millisecond.

[A] All the drives involved are NTFS which is why I was surprised that the timestamp was not being honoured faithfully in the way that MS windows copy does.

A The donor arrays are 1.6GB NTFS partitions in MBR drives and the receiving array is 3TB GPT.

When files are copied from an NTFS drive to a FAT drive the timestamps can change by up to 2 seconds but the files remain the same

I am aware of that but FAT is not a factor when one is dealing with 30TB of data.

THE PROBLEM is that when copying files from NTFS to NTFS , VVPro is rounding the timestamp down and not copying it faithfully.

In my book that is a BUG as your programmer has had to out of their way to change the timestamp.

Andy

TGRMN Software · Site Admin Joined: 10 Jan 2005 Posts: 8769

Hi Andy, thanks. Sorry I had misunderstood your initial post. Currently ViceVersa timestamp resolution is down to the second, milliseconds are not copied. I have logged this as a feature that can be added in a future release. Are you using Powershell to check the milliseconds of files? thank you
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

akeogh · Joined: 08 Jan 2011 Posts: 3

I have my own utility that builds a catalogue for each disc with the attributes, date& timestamp, sumcheck, filesize, filename and path for every file and directory. There is then an option to check the catalogue against the disc and spot any changes.
Since it started life in 1991 when only FAT16 was around, it only records dates in increments of 2 seconds.
I only spotted the issue because 2 second time differences started showing up when I was commissioning a new machine with no data on the raid packs changing other than migrating from MBR to GPT so that I could move beyond the 2GB limit of MBR.
The problem has probably been there since I started using VVPro in 2004 but as I used to ignore a 6 second difference it is only recently that I have had the time to chase down the cause.
I now record the full timestamp so it will have whatever accuracy windows makes available in the C++ call filetimetosystemtime.

Andy

TGRMN Software · Site Admin Joined: 10 Jan 2005 Posts: 8769

Thanks, in Powershell this command can be used to show the milliseconds of a file:

$(Get-ChildItem C:\temp\file.txt).lastwritetime | fl
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

Guest · Guest

This "issue" still exists. Even the newest version (ViceVersa Pro 5 Build 5005) cuts the milliseconds (NTFS -> NTFS).
The problem is, that other tools (Robocopy, or "LastWriteTimeUtc" in C#) determine a difference between source and target if the milliseconds are gone.

Manfred

TGRMN Software · Site Admin Joined: 10 Jan 2005 Posts: 8769

Hi, thank you for the report, we are looking into adding support for millisecs in ViceVersa version 6.
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

TGRMN Software · Site Admin Joined: 10 Jan 2005 Posts: 8769

Hi, this fix is available to test in version 6 beta... please e-mail support if interested, thanks!
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

Guest · Guest

Thank you for the update.
I will contact the support team to test it in the beta version.

Guest · Guest

In ViceVersa BETA 6 (Build 6003) the milliseconds exists even in the target with the new option.
The new millisecs option is in : profile settings -> advanced settings
-> more.

Thank you for your support and quick fix.