Error writing to synchronization database

Get help for specific problems
Posts: 6
Joined: 16 Feb 2010

alokg

It at first says no database exists. I ignore (assuming this will create the
database).
Next it says:

Error writing to synchronization database:
"F:\sync.ffs_db.tmp"
Ignore this error, retry or abort synchronization?

Please help!
User avatar
Site Admin
Posts: 7048
Joined: 9 Dec 2007

Zenju

For some reason it fails to write to F:\. May it be that this drive is write-
protected?
Posts: 6
Joined: 16 Feb 2010

alokg

FreeFileSync is able to synchronize files on this drive with a network
location in both directions, so it clearly has write access. I double-checked
still. I have >30GB free on F:

By the way, am using Windows 7 64 bit.
User avatar
Site Admin
Posts: 7048
Joined: 9 Dec 2007

Zenju

Has it worked already at some point in time? Are you using the most recent
version?
Posts: 6
Joined: 16 Feb 2010

alokg

Using for the first time. Yes, using most recent version (3.3). Never worked
(syncs fine, always fails to save database).

I had two hard-drives (desktop and laptop) that I am trying to sync. They both
started by having the same data which I had replicated from desktop to laptop
by manually copying over. Then I started using FreeFileSync. Works fine except
that database cannot be saved. So I currently have to inspect the changes
manually to make sure files I delete at one location do not come back on sync
from the second location.
Posts: 6
Joined: 16 Feb 2010

alokg

It worked. Sorry. It WAS an access-denied issue. I am administrator and have
full control over F:. Yet, SOMEHOW, FreeFileSync was not running with
administrator privileges and so was getting access denied.

It would be nice though if FreeFileSync gives more detailed error messages
saying what went wrong rather than just saying 'cannot create database'.

Please close the issue as solved.
User avatar
Site Admin
Posts: 7048
Joined: 9 Dec 2007

Zenju

> It would be nice though if FreeFileSync gives more detailed error
messages...
Unfortunately saving this db-file is one of the few places where I completely
rely on the wxWidgets algorithms to compress and serialize data. In contrast
to all the other file access algorithms which I programmed myself, I have very
little means to determine what exactly went wrong.

But anyway: It's strange that you were allowed to copy to and delete regular
files from F:\ during synchronization but still not allowed to write the db-
file on F:\. Could it be that it was some specific permission, that allowed
everything exept writing a file? If I knew exactly what the problem is, I
could include a check somehow. It wouldn't make sense if one required admin
rights, just to write this single db-file...
Posts: 6
Joined: 16 Feb 2010

alokg

> But anyway: It's strange that you were allowed to copy to and delete regular
files from F:\ during synchronization but still not allowed to write the db-
file on F:\. Could it be that it was some specific permission, that allowed
everything exept writing a file?

Some more information:
1. I am administrator.
2. Administrators had full control of F:
3. Normal users did not have full control. Only read/execute.

Two surprises observed:
1. Since I had full control, it should have been able to write the database to F:. But it was able to write only after I gave full control of F: to normal users.
2. Even without full control (only read / execute access), it is able to sync files in both directions.

It seems then that FreeFileSync is using admin rights to move files around,
but wxWidgets is sticking with rights of a normal user.
User avatar
Site Admin
Posts: 7048
Joined: 9 Dec 2007

Zenju

1.) That's understandable: If you start not in admin mode, you are a standard
user from the tool's point of view (It doesn't matter that you are logged into
Windows as an admin.)

2.) This is suprising. The only explanation that I can think of is, that for
copying a file other permissions are required than for creating and writing a
file.
But if normal users only have "read/execute" permission, then it shouldn't be
possible to delete and copy files on the share. -> It would be interesting to
know, why this was possible.

> It seems then that FreeFileSync is using admin rights to move files around,
FreeFileSync only can only work with the permissions it receives, it cannot
choose it's own permissions. If it is started as a standard user then
everything it does is also possible for a standard user.