Timestamp issue with ibackup.com network drive

personalt · Joined: 21 Jan 2006 Posts: 1

i use the backup service ibackup which is an online drive like xdrive.

When i sync from the desktop drive to networked drive files that get copied to the network drive are created with a current timestamp rather then the original files timestamp.

the file then gets copied back down on the next sync as the networked copy is newer. the weird thing is on the copy back down the timestamp gets set correctly. well i guess that is not that weird as the drive to copy back down to is the local drive

is there anyway to get the proper timestamp on a network drive hosted on a online provider like idrive?

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

Does it maintain the original file timestamps when uploading using the Windows Explorer? thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

mlabbe · Guest

Funny . . . I was just checking the forum for exactly the same
symptom, but different setup. I'm synchronizing local directories to
NetBIOS shares over the internet, over my company's VPN. At first, I
thought it was a time zone issue (currently 8 time zones away) which
could be corrected by setting the time offset, but then I realized the
newly created files are getting the time stamp of the time when the
copy operation is finished, not the time stamp from the local copy.

I did the following test:

1. Create local file called foo.txt. Local is source, and remote
share is is target. Configuration for synchronize mode with
size/timestamp comparison.
2. Do compare: local: foo.txt 09.58.45 remote: none
3. synchronize
4. Do compare: local: foo.txt 09.58.45 remote: foo.txt 10.01.09
5. synchronize
6. Do compare: Now the files match (source & target identical)
7. Modify local foo.txt
8. Do compare: local: foo.txt 10.05.34 remote: foo.txt 10.01.09
9. Synchronize
10. Do compare: local: foo.txt 10.05.34 remote: 10.06.51
11. Synchronize
12. Do compare: Now the files match (source & target identical)

Second test:
1. Create a new local text file called bar.txt (timestamp 10.08.19)
2. copy/paste from local directory to remote share using windows explorer
3. Check the file properties on the remote copy: (created 10.10.15,
modified 10.08.19)
4. Do compare in vvpro: source and target are identical

So, the correct timestamp (the "modified" field) is carried over when
using windows sharing to move the file, but not when using vvpro to
move the file.

Third test:
1. Modify foo.txt and check attributes: created 09.56.22, modified 10.15.22.
2. compare in vvpro local: 10.15.12, remote: 10.06.51
3. synchronize
4. compare in vvpro: local: 10.15.12, remote: 10.17.44
5. Check attributes on local: same as above
6. Check attributes on remote: created 09.56.22, modified 10.17.44

So, something in the way vvpro is copying the file over to the remote
touches the "modified" attribute.

The result of this is that we have to sync twice to get everything in
sync, which is tough with huge directories and slow Internet links.

Just some further information, I'm running XP, NTFS filesystem
locally. Remotely, I think they have some Network Appliance storage
arrays, but I'm not sure exactly.

Can you guys think of any workaround for this? Is it a bug, or an
artifact of the way the filesystems work? Oh, why don't I see this
when synching with local XP <--> XP shares over a LAN?

Thanks for any info you can provide.

Cheers,
Matt

mlabbe · Guest

Any updates?

Thanks
-Matt

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

Sorry for late reply, which version / build of ViceVersa are you using? To find please selct help->about from the main menu. thanks.
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

mlabbe · Guest

No worries, thanks for writing back.

Version is current from the web site:
ViceVersa Pro 2
Registered Version
Copyright© 2001-05 TGRMN Software - Build 2.0.0.9
Web Site: www.tgrmn.com E-Mail: info@tgrmn.com

Cheers,
Matt

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

mlabbe, I think we need to send you a special debug version for this. Can you please write to support@tgrmn.com? thanks
By the way, can you perform the same tests with a log file enabled (in the profile settings), so we can check what is reported in the log file....
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

mlabbe1 · Joined: 10 Feb 2006 Posts: 8

Just sent you guys an e-mail. More than happy to try a debug build for this. I'll get you a log file as soon as possible.

Cheers,
Matt

mlabbe1 · Joined: 10 Feb 2006 Posts: 8

OK, I ran a simple test with a single file, foo.txt.

Profile is set to "replicate" mode with logging turned on.
* Create text file foo.txt on local machine
* synchronize with directory on remote machine
* run compare, timestamp is out of sync.
* synchronize with remote directory again
* now timestamps are in sync

So, for any locally modified file, two replications are required to synchronize.

Ran this test twice with logging enabled. Log file is attached . . . woops no it isn't, can't attach files. I'll e-mail the log separately.

Cheers,
Matt

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

thanks, got the log file

It looks like the first time the file is copied over it gets the wrong timestamp. Next run, when the file is updated, it gets the right timestamp.

We are about to release VV PRO build 2010. I suggest that you test with that version and if the issue still remains we will build a special debug version to check why the timestamp issue occurs over your VPN connection. Just to confirm: when you copy a new files over the VPN with the Windows Explorer it gets the right timestamp the first time ?

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

mlabbe1 · Joined: 10 Feb 2006 Posts: 8

Another way to say it is that when the file is sent from the local to the remote device the timestamp is wrong but when it comes from the remote to the local device it gets corrected.

Doing a straight Windows explorer copy *does* put the correct timestamp in both directions.

When is the new version coming out? I need to get this issue resolved pretty quickly.

Cheers,
Matt

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

Pre-release of build 2010 is available here:
http://www.tgrmn.com/web/forum/viewtopict488.htm

Not sure if the new build will fix the issue you are seeing. Let me know. What is strange is that VV does not even report an error but the timestamp is wrong, that is very strange. If build 2010 still does not work for you, we have another change we would like to try implement to possibly fix this. thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

mlabbe1 · Joined: 10 Feb 2006 Posts: 8

Nope, no luck. Ran the same test with the 2010 build and still have the same issue.

Given the failure symptoms, it doesn't seem strange to me that there's no error message. It's just that the file's "modified" attribute is getting set to the "created" date instead of being copied over from the original file as it should be. Nothing that would flag an error condition, just incorrect behavior.

Let me know what else we can try.

Thanks,
Matt

mlabbe1 · Joined: 10 Feb 2006 Posts: 8

Any Updates?

Thanks,
Matt

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

Can you download and install the old ViceVersa PRO 1.3.1 and tell me if it works OK or not?

http://www.tgrmn.com/web/downloads/vvpro131.exe

You do not need to uninstall ViceVersa PRO 2.

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