Synctoy 1.4 problem

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I used synctoy 1.2 until I had a virus problem and had to reformat the hard
drive and reinstall all my software. 1.2 worked flawlessly on my
wired/wireless network of 3 computers.

After reformatting the HD I downloaded synctoy again to install it and got
the latest version, 1.4. I now have problems in syncing the three folder
pairs that I manage with synctoy.

I receive errors on a number of files. It says Error: The process cannot
access the file because it is being used by another process... followed by
the to and from path and filenames.

As far as I can tell, these files shouldn't be used in any current process.
Many are url files and IE is closed on both related PCs as well as a number
of .doc and other files whose applications are closed are the respective PCs.

Has anyone else run into this problem or do you have any suggestions.
 
I haven't used 1.4 as there have been issues reported by other users. There
is now a user's group for all of the WinInternals (SysInternals) utilities
you might want to post there also.

It's: microsoft.public.wininternals

It's new so to date there are not a lot of posts.

JS
 
Thanks. I'll post the message there as well.

I forgot to mention in the original post that Synctoy placed files in the
target directories followed by "_SyncToyBackup" plus a 17 digit number
representing the date and time. However, this file generally doesn't work as
expected when opened, especially when it's a favorites URL.

BTW, do you know where I can get version 1.2. I'd gladly go back to that
since it worked like a charm for my purposes.
--
Thanks,
Joe S


JS said:
I haven't used 1.4 as there have been issues reported by other users. There
is now a user's group for all of the WinInternals (SysInternals) utilities
you might want to post there also.

It's: microsoft.public.wininternals

It's new so to date there are not a lot of posts.

JS
 
Version 1.2: http://www.google.com/search?hl=en&q=Synctoy+v1.2

JS

joes said:
Thanks. I'll post the message there as well.

I forgot to mention in the original post that Synctoy placed files in the
target directories followed by "_SyncToyBackup" plus a 17 digit number
representing the date and time. However, this file generally doesn't work
as
expected when opened, especially when it's a favorites URL.

BTW, do you know where I can get version 1.2. I'd gladly go back to that
since it worked like a charm for my purposes.
 
Much appreciated. What a difference a "v" makes. I googled Synctoy 1.2 and
all the links that looked good on the first couple pages took me to reviews
or downloads for 1.4. Version 1.2 doesn't appear to be on Microsoft's site
any longer.
 
Joe, I work on SyncToy and would like to understand the problem better. We're
currently working on the next release of SyncToy and would like to fix any
bug you're encountering. We will have better error handling support in the
next release where sync won't fail if single file fails to synchronize -
we'll just skip the file.

Is there a way for you to use a tool like Process Explorer to check whether
the files in question are really being held open by any other application?

Thanks,
-ashish
 
Ashish,

I downloaded the tool. I'll use it and let you know what I find. I'll
check after reinstalling 1.4 (I was going to revert back to 1.2) if there's a
way to capture the error messages so I can send you the details if those will
help you in identifying the problem. If there's no obvious way, like cutting
and pasting, do you know of another way?
 
Ashish,

Haven't used the PE tool before so hopefully I did this right. I
reinstalled Synctoy 1.4 and set up a folder pair between my desktop and
laptop. Ran PE on both PCs and then ran the folder pair sync. First run
said one new file was transferred to laptop but I couldn't tell which one
that was. Went into MS Word and changed a file in the desktop folder
included in the folder pair. Closed Word and ran synctoy again. This time
it gave me the same error I was getting before, Operation-Overwrite, Error:
The process cannot access the file because it is being used by another
process... I performed a Find/Handle or DLL substring on both PCs. The file
was not found on either. I checked for the file on the laptop and found that
the original file (Sites.doc) no longer showed up. However there is now a
file named Sites.doc_SyncToyBackup_20070510123240906 with a generic icon
rather than the MS Word icon. (It did this to 40 or more files that
encountered this error when I ran synctoy the other day. After uninstalling
synctoy yesterday I also searched for all files and folders containing
synctoy or SyncToyBackup and deleted those on both PCs.)

I then opened the file on the Desktop computer in Word and did the PE search
again to see if I understood the process correctly. It found the open file,
Sites.doc.

Let me know if you need any additional information or if you would like to
log onto my PC remotely to further diagnose the problem.
 
Joe, it seems like you might have a program installed (such as an anti-virus
scanner) which is kicking in after the files are changed. The SyncToyBackup*
files are temp files that are created during the copy process. SyncToy copies
the source file to a temporary location and then moves the temp file to the
destination location (for maintaining file consistency). In this case, the
move to destination seems to be failing because the destination file is being
used by another program. SyncToy uses normal OS APIs for file access which
may fail if another program has the file handle open transiently. Can you
try to see if you get the same behavior if you wait for some time (maybe a
few minutes) between changing the file and syncing it?

We will keep trying to reproduce this issue here locally but it will be
great if you can keep tinkering to find out which program might have the file
open. I will respond to this thread if we're successful in reproducing this
problem here and find a solution to it.

A couple of ways in which we will improve this experience in the next
release - we will not create the temp file if we can't get an exclusive lock
on the destination file, and we will not fail the sync if we run into any
file copy errors like this.

Thanks
Ashish
 
Ashish,

I gave that a try with a single file change, but still have the same
problem. It may not be from changing the files. When I first upgraded to
1.4 I had this problem and ran into over 50 files that wouldn't copy
correctly while hundreds did. But, nearly all of the problem files had not
been used for weeks or months.

Let me know if there's any other information I may be able to give you that
would be of help or if you'd like to log onto my PC remotely to look for any
other causes.

Glad to hear you'll be addressing the problem in the next update. In the
meantime I'll revert back to 1.2. If I run into any problems there, it may
be that some change in my system is causing the problem. What's the best way
to insure I completely remove 1.4?

Since changing to 1.4 there has also been another major change on the
desktop PC. I no longer use Norton Internet Security and have switched to
BitDefender v10 for antivirus and antispyware. I didn't think this should
have any bearing on the open files but thought I'd mention it in relation to
your comment on anti-virus scanners.

On an unrelated note, if a file is changed on both sides, will changes from
both files be incorporated on both sides or only the newer of the two files
copied to the other location? If the latter, is there a way to include the
changes from both files in the resulting files on both sides or can that be
built into the next version?
 
Joe & Ashish -

I have been racking my brain on this issue for the last week until I came
across this thread.

I have exactly the same issue, running Windows XP SP2.

I ALSO have switched to BitDefender 10 recently.

What are the odds? Must be BitDefender. I am going to try disabling it
right now and starting all over with Synctoy - I will report back, but in the
meantime I thought I would let you know.
 
Success!!!!

Follow up..

I (1) put BitDefender 10 in "maintenance" mode (disables most protections),
(2) used search to locate and then delete all SyncToyBackup files on my
network drive (which is a CIFS drive on an Infrant NV network storage
device), (3) deleted all of the files in SyncToyData, and (4) rerand synctoy
1.4 and recreated my network pairs. Everything worked (and, I might add, 10x
faster than before). Zero errors, no crazy synctoybackup files, just 10GB
of music synced beautifully!!!

Thanks for the tip and hope this works for everyone else with this issue
(and hopefully this will help MS fix the problem or at least coordinate with
Bitdefender better.
 
Jeff,

Just caught up on my email and got notice of your responses to my last post.
Tried your experiment, setting BitDefender into Maintenance mode. It worked
perfectly and speedy!! Great work.
 
All,

just to add to this thread, i'm having the same problem, but the antivirus
software on my work computer is the full version of Symantec (version
10.1.0.394). This issue has only started recently.
I copy files from a network onto a usb hard drive which i then access on a
home computer.

The problem files are Adobe InDesign and Illustrator files, although i don't
think it's limited to these types.

I can't even delete the out of date and temp files on the USB drive in order
to replace them - although i think i can to do this from my home computer
which i don't sync up.

Unfortunately I doubt i'll be able to respond to further posts as i'm out of
the country next week.

All very frustrating.
 
Corrupted file with with SyncToy

Hi "SyncToy" Guys,


I have just discovered a "Bande1.avi_SyncToyBackup_20080602074901750" (482 MB) file in my movies directories with a "Bande1.avi" (7.4 GB) corrupted file.
I missed this point a few months ago and now it's seems too late to remember when this error occurs.
I have the same files in the two PC wich were synchronized.

Is there a way to recreate the correct file with this two parts ?

I don't remember if I was running SyncToy 1.4 or 2.0 at this time.
 
Back
Top