Every so often (Maybe once a month), the batch sync routine will be syncing
during a server bogging down with some other task.
So today, had a server slowdown and in the log, got this....
Error: Error traversing directory:
"\\darknight\y$\Projects\0512"
Windows Error Code 64: The specified network name is no longer available.
Error: Error traversing directory:
"\\darknight\y$\Projects\"
Windows Error Code 6: The handle is invalid.
And then it went to work and deleted everything past the 0512 folder. Now I
had it drop the deleted files to a sync folder, so was able to restore it (yes
I do have backups, but this was easier to restore). But can I do something to
the ffs_batch so that if this error comes up (or some other error), it should
just bail so as not to see everything as a "deletion"? I'm on freefilesync
3.16 with 2003 x64 server R2 sp2 network syncing with sbs 2003 (x32). I have
this on a task schedule for every 10 minutes, so I can easily live with
waiting till the next round, but having the boss show up at my door asking
where everything went, a bit nerve-racking if you know what I mean.
Network share Hickup
- Posts: 1
- Joined: 20 Jul 2011
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Coincidentally I'm currently working on a solution for this (up to your post
only hypothetical problem). It's reassuring that a new handling is really
required. In general FFS already has a safety-check implemented at a global
level that detects whole (temporary) network drops and stops synchronization
for a foler pair. The reason for why "the source" drive is not accessible,
doesn't matter, so it's a very generic and powerful saftey mechanism.
What's currently not implemented is a more fine granular handling if only a
part of input data cannot be read. This may be due to permission problems or
network lags, as in your case. I have this on my agenda for v3.19.
only hypothetical problem). It's reassuring that a new handling is really
required. In general FFS already has a safety-check implemented at a global
level that detects whole (temporary) network drops and stops synchronization
for a foler pair. The reason for why "the source" drive is not accessible,
doesn't matter, so it's a very generic and powerful saftey mechanism.
What's currently not implemented is a more fine granular handling if only a
part of input data cannot be read. This may be due to permission problems or
network lags, as in your case. I have this on my agenda for v3.19.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> can I do something to the ffs_batch so that if this error comes up (or some
other error), it should just bail so as not to see everything as a "deletion"
Just forget to mention, as it's probably self-evident: Set error handling to
"exit instantly" instead of "ignore errors".
other error), it should just bail so as not to see everything as a "deletion"
Just forget to mention, as it's probably self-evident: Set error handling to
"exit instantly" instead of "ignore errors".
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Done: "ignore errors" can now safely be used in all circumstances, also in
case of failure to access certain sub-directories as discussed above. In this
case, the corresponding files/directories on the other side will be disabled =
excluded from synchronization. This exclusion can be overwritten manually in
GUI mode if required. Implemented for v3.19!
case of failure to access certain sub-directories as discussed above. In this
case, the corresponding files/directories on the other side will be disabled =
excluded from synchronization. This exclusion can be overwritten manually in
GUI mode if required. Implemented for v3.19!
