Database Files

[arsecandle]

Before I begin, I'd like to say that your software kicks all the other backup software's asses
Now, I have a bone to pick with you regarding the creation of sync.ffs_db...

Creating it in the root of the folder which it represents is madness because:
a) it makes it vulnerable to deletion from inexperienced or unknowing users
b) its presence potentially causes problems for software that expects a certain number or type of file to be present in a folder, e.g.: Thunderbird email DB
c) if the sync relationship lives within the folder structure of a another sync, the db is sync'ed (although I think you fixed that)

I understand that it is meant to accompany the folder it represents in order to maintain its relevance, should the root folder be relocated. However, in this event the db loses its significance because repositioning the root effectively invalidates any previous sync relationships, or is that just my opinion?!

Thus, I would like to argue for the housing of db files within the folder structure of FreeFileSync itself, e.g.: in a sub-folder called 'SyncDBs' where each file is given an index number and an accompanying ini file stores the index/root relationship (and anything else that might prove worthy, e.g.: stats)

I also think this DB move would benefit any future plans to build in some degree of overall backup/sync management, e.g.: stats of data moved / created / deleted from a global to a specific level, scheduling, conflict resolution, etc.

[Plerry]

> Thus, I would like to argue for the housing of db files within the folder structure of FreeFileSync itself, e.g.: in a sub-folder called 'SyncDBs' where each file is given an index number and an accompanying ini file stores the index/root relationship (and anything else that might prove worthy, e.g.: stats)

That would only work if FFS is only run on/from a single PC.
If you have multiple PC's syncing to/with the same location, your proposal does not work.

[xennex83]

I think your suggestion is problematic.

For one, a program never stores such data in the program file structure of the program, but (on Windows) in AppData/Roaming or something similar. Thus you could argue for central storage in such a (user) location.

But the general opinion is that portable == good. As Pierry indicates. you are then bound to a single computer storing this data. That is a pretty vulnerable situation to begin with. It makes whatever backup you have less portable. Even without knowing how it works, I can see that this would not be very good.

I would however agree that the visibility of this item is unwarranted. I would personally suggest to include this database file in a hidden subdirectory. Well, it is already hidden.

I just think it is good practice --- but that is just on Unix systems... On a Unix/Linux system I would create a hidden .freefilesync directory containing a non-hidden file. But on Windows... since I have hidden files as visible (or several important places become inaccessible, like the AppData folder...).

Well, it is just personal. The root of my folder hierarchy only contains folders, no loose files. Therefore, the "sync.ffs_db" file stands apart, which is nice. A hidden "sync.ffs" folder still stands apart enough. It doesn't really matter all that much.

BUT I would still prefer to have the file located in such a folder instead of the root, for reasons that you indicate: it is very vulnerable.

I vote for putting the db file in a hidden subdirectory of the root location, that it currently resides in.

[blues12]

I run FFS portable from a stick. Often the db-files are gone missing on foreign drives, systems, companies. Their cleanup-routines or whatever else deletes them.

I vote for an ini-tweak or GUI-option to set the db-location.
Even better were no db-file at all. Don't know if it's really necessary for users like me who never use 2-way syncs but stick to one-way directions only.

[echtatze]

I also run FFS from a portable stick.

I would vote to make this optionally configureable in the .ffs_batch or .ffs_gui files.

This could be done in the "<FolderPairs>" node for each defined folder there.

The default could be the current way, if nothing is configured there.

The possible options could be a defined with keywords like for example
"SyncFolder" (what would be the current way)
"HiddenSubFolder" (this is what Bart suggested)

or a custom value like
"P:\FreeFileSync\DBs\MySyncFileNumber1.ffs_db"

or with auto replaced values like
"[AppFolder]\MySubFolder\MySyncFileNumber1.ffs_db"
([AppFolder] would be substituted by FFS with the full path of the folder where the current exe is)

or
"%APPDATA%\FreeFileSync\MySyncFileNumber1.ffs_db"
(%APPDATA% would be substituted by FFS with the value of the same named environment variable)

This surely are just some examples.