Hi,
First I just want to say thank you for all your hard work and for making this
freely available. I am just starting with FreeFileSync, but it looks great.
First, a little background:
The reason I need folders to stay in sync is because I work in a branch office
that has files and standards stored in our main office. We have mapped network
drives that are connected to a file server over a slow VPN connection (its
really complicated, but our IT department just cant seem to set up a decent
network, so I began looking into options). The files and standards have the
chance of being updated at anytime, therefore we need the same files that our
main office is using. The connection is constantly cutting out, so I figured
that if we synced the mapped network drives to our local machines, all
problems would be solved as our programs would be accessing the local files,
and when changes were made, they would be propagated to our office (or from
our office to the main office).
The problem:
As you probably guessed, I am running RealtimeSync to meet my needs. Sometimes
when the network drops, I get the following pop-up message:
"Error when monitoring directories.
Windows Error Code 64: The specified network name is no longer available."
The only option is to then click "Ok", and upon doing so, the RealtimeSync
stops running and the usual interface (the one that appears when opening the
RealtimeSync.exe) then pops up. So I must then press "Start" to get it to run
again.
I had thought RealtimeSync was supposed to be able to just "hang out" until
the path/drive becomes available again, and then when it was, it would
compare/sync, and then continue to monitor changes.
I have been able to recreate this error at home as well. I mapped a share from
my laptop to my desktop, and then on the desktop, synced a folder to the
mapped drive (say, the 'S' drive). My desktop connects to the Internet/Network
through a wireless USB device, so to mimic a network drop, I would just unplug
the USB device.
My system:
Windows 7 x64 Pro (both at work and home)
Any help is appreciated.
Thank you!
Windows Error Code 64
- Posts: 10
- Joined: 19 Sep 2011
- Posts: 10
- Joined: 19 Sep 2011
Sorry, I forgot to mention that I am using the lasted release, version 3.21. I
also just tried a newer beta version I found in another post (v3.22 beta8),
and i still had the same problem, except that the error pop-up message read
slightly different:
"Error when monitoring directories. (GetOverlappedResult)
Windows Error Code 64: The specified network name is no longer available."
With the "(GetOverlappedResult)" being the additional text that was not
included in v3.21
also just tried a newer beta version I found in another post (v3.22 beta8),
and i still had the same problem, except that the error pop-up message read
slightly different:
"Error when monitoring directories. (GetOverlappedResult)
Windows Error Code 64: The specified network name is no longer available."
With the "(GetOverlappedResult)" being the additional text that was not
included in v3.21
- Posts: 10
- Joined: 19 Sep 2011
And by "lasted version", I meant "latest version". Sorry, I hate spelling
errors (even though I always make them!)
errors (even though I always make them!)
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Hi,
thank you for the detailed report information *and* going the extra route
checking with the newest beta and showing the detailed error messages. This
saved a lot of time!
I checked the sources and found RTS may occassionally not check directory
existence in case of failure, like the one describe above. This is because it
checks at most every 1 second. If the directory drop happens at the wrong
time, the network failure is not replaced by the proper "directory not
existing" status but is propagated instead. This issue has been fixed, here is
the new version for testing:
[404, Invalid URL: http://ifile.it/jaeyfp2/RealtimeSync_x64.exe]
Regards, Zenju
thank you for the detailed report information *and* going the extra route
checking with the newest beta and showing the detailed error messages. This
saved a lot of time!
I checked the sources and found RTS may occassionally not check directory
existence in case of failure, like the one describe above. This is because it
checks at most every 1 second. If the directory drop happens at the wrong
time, the network failure is not replaced by the proper "directory not
existing" status but is propagated instead. This issue has been fixed, here is
the new version for testing:
[404, Invalid URL: http://ifile.it/jaeyfp2/RealtimeSync_x64.exe]
Regards, Zenju
- Posts: 10
- Joined: 19 Sep 2011
Zenju,
Thanks so much for the quick response and updated exe. This is really an
awesome community here.
Your update seems to have fixed the problem (once again, tried it at work and
at home - success at both locations). However, there is a slight (and which I
believe to be very minor) bug now when opening RTS.
To detail my steps:
I placed the "RealtimeSync_x64.exe" in the following path:
C:\Program Files\FreeFileSync\Bin
and overwrote the old file. Then I double clicked the RTS shortcut I made on
my desktop and received the following error pop-up message:
"can't open file 'C:\Program Files\FreeFileSync\Resources.zip' (error 2: the
system cannot find the file specified.)"
I'm guessing the file that is supposed to be referenced is the "Resources.dat"
file in the same location? Also (and probably related to the same error), the
RTS "red circling arrows" icon is no longer showing up in the system tray. The
program still runs, but there is just a blank icon there.
Thanks again for the help.
Thanks so much for the quick response and updated exe. This is really an
awesome community here.
Your update seems to have fixed the problem (once again, tried it at work and
at home - success at both locations). However, there is a slight (and which I
believe to be very minor) bug now when opening RTS.
To detail my steps:
I placed the "RealtimeSync_x64.exe" in the following path:
C:\Program Files\FreeFileSync\Bin
and overwrote the old file. Then I double clicked the RTS shortcut I made on
my desktop and received the following error pop-up message:
"can't open file 'C:\Program Files\FreeFileSync\Resources.zip' (error 2: the
system cannot find the file specified.)"
I'm guessing the file that is supposed to be referenced is the "Resources.dat"
file in the same location? Also (and probably related to the same error), the
RTS "red circling arrows" icon is no longer showing up in the system tray. The
program still runs, but there is just a blank icon there.
Thanks again for the help.
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
In the next version, release planned for this weekend, Resources.dat has been
renamed to Resources.zip. The version I sent above already looks for the
latter, which I forgot to provide. Anyways, this problem won't be in the final
release.
Regards, Zenju
renamed to Resources.zip. The version I sent above already looks for the
latter, which I forgot to provide. Anyways, this problem won't be in the final
release.
Regards, Zenju
- Posts: 10
- Joined: 19 Sep 2011
Zenju,
Since the new release, I am still having intermittent problems with RTS
regarding the Windows Error Code 64.
I uninstalled v3.21 and installed the new 4.0 release, just to be sure nothing
from the old version was lingering around. From time to time, I am still
getting the same message:
"Error when monitoring directories. (GetOverlappedResult)
Windows Error Code 64: The specified network name is no longer available."
I tried to reproduce this at work and home by unplugging the Ethernet cable
(at work) and the USB wireless card (at home). But with both those tests, RTS
operated correctly with the task tray icon fading in color, and upon mouse
hover a notification popping up saying “Waiting for directories…” (or
something like that). So basically RTS seemed to respond perfectly.
However, at work, our network cuts in and out, many times going in and out for
like split seconds. This is when RTS will give the error message and then stop
running, with the dialog/startup box popping back up. For email, my company us
MS Outlook and an Exchange server. The only bit of information I can give that
may be helpful is that every time RTS fails, also get a message some like.
“The connection to Microsoft Exchange Server as been lost.” So all I can think
is that this drop is seen differently by RTS then when I unplug the internet
cables, however, I don’t know a lot about networking so I’m not sure if that
even makes sense.
Since the new release, I am still having intermittent problems with RTS
regarding the Windows Error Code 64.
I uninstalled v3.21 and installed the new 4.0 release, just to be sure nothing
from the old version was lingering around. From time to time, I am still
getting the same message:
"Error when monitoring directories. (GetOverlappedResult)
Windows Error Code 64: The specified network name is no longer available."
I tried to reproduce this at work and home by unplugging the Ethernet cable
(at work) and the USB wireless card (at home). But with both those tests, RTS
operated correctly with the task tray icon fading in color, and upon mouse
hover a notification popping up saying “Waiting for directories…” (or
something like that). So basically RTS seemed to respond perfectly.
However, at work, our network cuts in and out, many times going in and out for
like split seconds. This is when RTS will give the error message and then stop
running, with the dialog/startup box popping back up. For email, my company us
MS Outlook and an Exchange server. The only bit of information I can give that
may be helpful is that every time RTS fails, also get a message some like.
“The connection to Microsoft Exchange Server as been lost.” So all I can think
is that this drop is seen differently by RTS then when I unplug the internet
cables, however, I don’t know a lot about networking so I’m not sure if that
even makes sense.
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> our network cuts in and out, many times going in and out for like split
seconds
It seems the real issue in your case was a different one than what was fixed
before. Under the circumstances you describe, the only remaining possibility
that could explain RTS showing this error message is the order of events when
checking directory existence. When any of the Windows APIs report failure, RTS
checks again whether the corresponding directory is existing. If not, it
discards the error and waits until the directory becomes available.
What must have happened in your case is that first, GetOverlappedResult
returns error code 64, and the directory check that follows immediately after,
returns "directory existing". This situation is quite unlikely to occur for a
single event, but under "hard" conditions it may be triggered.
The solution is to "not check" directory existence again, and evaluate the
Windows error code directly.
Here is the fixed version, the error message from above is handled as
"directory not existing" without further checking
[404, Invalid URL: http://ifile.it/1lt4bip/FreeFileSync_v4.1_beta5_setup.exe]
Note that it is quite possible that there are a few other error codes that
need to be mapped to "directory not existing". Please inform me if RTS returns
error messages that fit into this category.
seconds
It seems the real issue in your case was a different one than what was fixed
before. Under the circumstances you describe, the only remaining possibility
that could explain RTS showing this error message is the order of events when
checking directory existence. When any of the Windows APIs report failure, RTS
checks again whether the corresponding directory is existing. If not, it
discards the error and waits until the directory becomes available.
What must have happened in your case is that first, GetOverlappedResult
returns error code 64, and the directory check that follows immediately after,
returns "directory existing". This situation is quite unlikely to occur for a
single event, but under "hard" conditions it may be triggered.
The solution is to "not check" directory existence again, and evaluate the
Windows error code directly.
Here is the fixed version, the error message from above is handled as
"directory not existing" without further checking
[404, Invalid URL: http://ifile.it/1lt4bip/FreeFileSync_v4.1_beta5_setup.exe]
Note that it is quite possible that there are a few other error codes that
need to be mapped to "directory not existing". Please inform me if RTS returns
error messages that fit into this category.
- Posts: 2
- Joined: 22 Nov 2011
I love FreeFileSync. It works great in WindowsXP. However, I get the "Windows
Error Code 64: The specified network name is no longer available." error
whenever I try to do a sync between a local disk and a mapped network drive.
On the failing system I am running Windows 7 Professional 32-bit.
The entire error message (modified for privacy) is:
"Error copying file:
"C:\<directory>\<filename>" ->
"L:\<directory>\<filename>.ffs_tmp"
Windows Error Code 64: The specified network name is no longer available. "
What can I do to help debug this error?
Error Code 64: The specified network name is no longer available." error
whenever I try to do a sync between a local disk and a mapped network drive.
On the failing system I am running Windows 7 Professional 32-bit.
The entire error message (modified for privacy) is:
"Error copying file:
"C:\<directory>\<filename>" ->
"L:\<directory>\<filename>.ffs_tmp"
Windows Error Code 64: The specified network name is no longer available. "
What can I do to help debug this error?
- Posts: 2
- Joined: 22 Nov 2011
I forgot to mention, I am running version 4.3 of FreeFileSync.
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
> What can I do to help debug this error?
Please open a new bug tracker item on this. This thread was about a specific
issue with RealtimeSync, which seems unrelated.
Further information I'd need would be what conditions trigger the problem, for
example: Is this behavior new for v4.3? Does it work when UNC syntax is used,
does it occur spuriously, etc.
Please open a new bug tracker item on this. This thread was about a specific
issue with RealtimeSync, which seems unrelated.
Further information I'd need would be what conditions trigger the problem, for
example: Is this behavior new for v4.3? Does it work when UNC syntax is used,
does it occur spuriously, etc.