Profiles OK in VV, fails in VVEngine

BLatSD · Joined: 12 Mar 2009 Posts: 40

Since switching over from XP to Windows 7, I have a profile or two that run fine without errors from ViceVersa, but generate errors when run from VVEngine. The errors is: "Execution completed with file copy/delete errors", and the specific error in the log is always "The size, attributes or timestamp of <file> have changed after comparison. For data security reasons this file will be skipped. Press 'Refresh' to recompare Source and Target."

Why this affects some profiles & not others, I haven't found the reason. All my profile settings as far as advance options are identical with the exception of source & target paths. Target drive is identical in all profiles. And why it all worked fine in XP but now not in Win7, I don't know either. And before you ask, the option "Copy even if timestamps change after comparison" is checked in all profiles (though I've seldom known this opton do any good at preventing this kind of problem). I've also tried various combinations of checked & unchecked marks under "Copy permissions, attributes, & streams."

Also, I've enabled a rerun of the profile when errors occured in VVEngine, but that doesn't help either (just generates the same error again).

BLatSD · Joined: 12 Mar 2009 Posts: 40

Just to further elaborate, (for example), when I rename a file in the source from filename.jpg to filename.jpeg, the profile runs without error in VVEngine. Wait a bit and rename it back, and the VVEngine profile generates the above error.

So the first time around, it has no trouble deleting filename.jpg from target and copying filename.jpeg to target. But going the other way around, deleting filename.jpeg generates the error.

And it has nothing to do with the number of chars in a file extension. The same operation with filename.txt to filename.text and back works perfectly!

By the way, the file(s) delete fine via window explorer & fine via ViceVersa (not engine).

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

Thank you, I'll try to reproduce this problem, can you please post the content of the profile file .fsf that gives this error (copy and paste).

What type of drive is the target drive?

BLatSD · Joined: 12 Mar 2009 Posts: 40

I should note at this point that I've worked around the problem by turning off archiving. But I'd really rather not do that, but for now it keeps things from turning into a mess. However, the pasted profile below is as it was with archiving turned ON.

BLatSD · Joined: 12 Mar 2009 Posts: 40

I've either resolved this properly or worked around it, not sure which.

Archiving was set to write to an external drive that used to be plugged into my old computer. Security permissions & Owner were all set to my user account on the old PC. I've changed the owner & sole account to "Everyone" with full prviledges & set the entire drive to inherit priviledges from it's parent & propogated changes to all child objects.

So in short, the message that ViceVersa was writing to the log, that it could not delete the target file due to target file changes in attributes since compare was not true & definitely led me down the wrong road.

It was the fact that it could not write to the archive location because of drive & folder permissions that caused the problem. Why it only produced the error with VVEngine and not with ViceVersa, I don't know.

Possibly changes outlined in the "Tray Icon is Always Gray" thread may have helped too.

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

Hello
yes, the error message is definitely wrong.
I think the problem manifested only under VVEngine because of the reasons we are discussing in the other thread.
thanks
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com

BLatSD · Joined: 12 Mar 2009 Posts: 40

Since my permission & UAC issues have been resolved under the other thread, I've focused on this problem and have become aware of some new information that should help you pin it down.

The problem results when a file in a VVEngine monitored source folder is renamed, and only when the profile is run from VVEngine (OK in VVPro). So if I merely update an existing file & resave it, everything archives fine. But if I rename that file, it copies over the newly renamed file to the target, but then the the "attributes have changed" error noted above occurs, and it can't delete the old named file from the target.

I don't know if it is a coincidence or not but all of these profiles in which this error occurs with archiving turned on all have only one source/target. And also for what it's worth, when the archiving operation begins, it always creates any necessary sub-folders in the archive. So it gets that far. It just doen't create the archived file when a rename occurs. But then on the other hand, should it? If only a rename occured, why would it have to archive the file in the first place?

So I think this pretty much eliminates any UAC, or drive/folder/file permissions issues. If it has permission to re-write an updated file, it should have permission to rename it too. And, I started remembering that I was having this error with Windows XP too, so it's not Windows 7 caused. There's something else wrong.

BLatSD · Joined: 12 Mar 2009 Posts: 40

I just noticed one other thing... Running VVEngine in "normal" mode (not as a service), if I designate the target (which is a network drive) using it's drive letter, the profile fails with "Target Not Found". Whereas if I designate it with UNC format, it does not fail.

BUT, I can run the profile using the drive letter in VVPro.

I just wish VVEngine would behave or act with the same priviledges as VVPro. It would solve all of these issues.

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

Hello
the difference is that the account running VVEngine is running in elevated mode and connection to the mapped drive is not made.
_________________
--
TGRMN Software Support
http://www.tgrmn.com
http://www.compareandmerge.com