Hi!
Before everything, i would like to congratulate you... this program is getting
better and better.
Now, there's something that i would like to say about the file sync.ffs_db.
You are saving this file in the folders that are synchronizing, i don't really
agree.
Think like this... If i want to have 2 sync configs for the same folder, but
in one o would like to exclude some folders and in the other config i just
want to include a specific folder. The problem is that the sync.ffs_db it
would be the same in the same folder, so one file would be overwritten.
So, i suggest you change this to:
1st - obligate the user to save the config in the first run, like this he will
have to save a file with config and you now have a name do save the database.
2nd - like this the user have the choice to put his config file wherever he
wants and have is config files all together in the folder he wants. (The
program folder, in a pen, in the folder he is synchronizing, etc. wherever)
3rd - Then you have a name to save the database to. And the user will know
that he will have a pair of files with everything he needs for that
synchronization. Ex: (syncdocs.ffs_gui) (syncdocs.ffs_db) in the same folder
he saved his configs.
4th - Like this, you don't change the original files, like you do when you add
the database file to the folders that are synchronizing and the user don't has
the risk that someone deletes the database file, because this way the user
don't has any control of this database file.
5th - You give all the control to the user creating the synchronization
configuration. And the user know that everything he needs is in the
place(folder) that he saved the configuration file.
Concluding, my opinion is that the file with the configuration and the
database file should work like a pair. If the user load a config file, the
program should try to read a database file with the same name.
I think this is the correct behavior.
Note: i hope i have explained correctly my point of view.
Thanks
Nuno Leite
: http://www.nunoleite.com
Automatic sync database
- Posts: 20
- Joined: 5 Dec 2005
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Hi Nuno,
> You are saving this file in the folders that are synchronizing, i don't
really agree.
> If i want to have 2 sync configs for the same folder, but in one o would
like to
> exclude some folders and in the other config i just want to include a
specific folder.
> The problem is that the sync.ffs_db it would be the same in the same
folder, so one
> file would be overwritten.
Have you actually tested this usecase? It should work correctly! Different
folder pairs are handled separately! (A <-> B and A <-> C handled
differently)
> I think this is the correct behavior.
I think there are multiple "correct" solutions, each with their
ad-/disadvantages.
Compared with your suggestions current approach has advantage of:
- clarity/ease-of-use: almost no user interaction
- avoid inconsistency: wrong/outdated/cloned database file cannot be selected -> hard to something wrong
- db located at one universal place: uscase portable USB, variable drive letter, switching sides
- not bound to specific configuration: works with any config, no maintenance at all.
Con:
No drawbacks (at least that I would know of)
Regards, Zenju
> You are saving this file in the folders that are synchronizing, i don't
really agree.
> If i want to have 2 sync configs for the same folder, but in one o would
like to
> exclude some folders and in the other config i just want to include a
specific folder.
> The problem is that the sync.ffs_db it would be the same in the same
folder, so one
> file would be overwritten.
Have you actually tested this usecase? It should work correctly! Different
folder pairs are handled separately! (A <-> B and A <-> C handled
differently)
> I think this is the correct behavior.
I think there are multiple "correct" solutions, each with their
ad-/disadvantages.
Compared with your suggestions current approach has advantage of:
- clarity/ease-of-use: almost no user interaction
- avoid inconsistency: wrong/outdated/cloned database file cannot be selected -> hard to something wrong
- db located at one universal place: uscase portable USB, variable drive letter, switching sides
- not bound to specific configuration: works with any config, no maintenance at all.
Con:
No drawbacks (at least that I would know of)
Regards, Zenju
- Posts: 20
- Joined: 5 Dec 2005
repeating the last post:
Hi!
For me there are some drawbacks:
1 If the database file is deleted? from that location?
2 You are adding files to the sync folders that the users don't want. At least
i don't... ;)
3 You are spreading files all over the places when we do a synchronization
(it's like the desktop.ini and thumbs.db windows uses). I don't like those
too...
4 When you save this database file, do you save everything? For example: I
have 5 folders in my drive E: if i want do select drive E: and make a filter
of only folder 1 and 2 to sync to another place, and then i want to create
another config from that drive E: of the folder 3 and 4 to another place. The
database file will be save in the same place (e:) so one will be lost. Or do
you run all the folders in drive E: for that sync and save it in the database?
I understand what you are saying, and the way you do can be simpler for the
regular user, but i would like to control that. If i have the 2 files in the
same place, i have sure that they wont be lost. În the future if i want to
delete this sync config, i just delete the 2 files, and the way you are using,
the database files that will be left will be garbage in the folders.
Tip: do you know Backer? Backer works the way i'm saying, it's a different app
but you can try it just to see and take ideas from that.
Thanks
Nuno Leite
:
: http://www.nunoleite.com
Hi!
For me there are some drawbacks:
1 If the database file is deleted? from that location?
2 You are adding files to the sync folders that the users don't want. At least
i don't... ;)
3 You are spreading files all over the places when we do a synchronization
(it's like the desktop.ini and thumbs.db windows uses). I don't like those
too...
4 When you save this database file, do you save everything? For example: I
have 5 folders in my drive E: if i want do select drive E: and make a filter
of only folder 1 and 2 to sync to another place, and then i want to create
another config from that drive E: of the folder 3 and 4 to another place. The
database file will be save in the same place (e:) so one will be lost. Or do
you run all the folders in drive E: for that sync and save it in the database?
I understand what you are saying, and the way you do can be simpler for the
regular user, but i would like to control that. If i have the 2 files in the
same place, i have sure that they wont be lost. În the future if i want to
delete this sync config, i just delete the 2 files, and the way you are using,
the database files that will be left will be garbage in the folders.
Tip: do you know Backer? Backer works the way i'm saying, it's a different app
but you can try it just to see and take ideas from that.
Thanks
Nuno Leite
:
: http://www.nunoleite.com
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> For me there are some drawbacks:
> 1 - 3
I agree on these drawbacks. But I'd categorize them more as cosmetic issues
rather than functional. So these problems alone IMHO don't justify additional
configuration options on GUI. In this case I prefer ease-of-use over
"clean sync-folders".
> 4 When you save this database file, do you save everything?
Although it's only one file, it contains several "entries", one for
each combination of folder pairs.
> I understand what you are saying, and the way you do can be simpler for
the regular
I understand your wish to take control here. But I also see your usecase more
as exception rather than the rule. And I am generally quite reluctant to make
concessions to special cases, at least when they might impede standard usage.
Maybe a quick custom hack like discussed here solves your requirement? [404, Invalid URL: https://sourceforge.net/tracker/?func=detail&%3Baid=2887039&%3Bgroup_id=234430&%3Batid=1093083]
> Tip: do you know Backer? Backer works the way i'm saying, it's a
different app but you
> can try it just to see and take ideas from that.
No. Thanks I'll have a look at it!
> 1 - 3
I agree on these drawbacks. But I'd categorize them more as cosmetic issues
rather than functional. So these problems alone IMHO don't justify additional
configuration options on GUI. In this case I prefer ease-of-use over
"clean sync-folders".
> 4 When you save this database file, do you save everything?
Although it's only one file, it contains several "entries", one for
each combination of folder pairs.
> I understand what you are saying, and the way you do can be simpler for
the regular
I understand your wish to take control here. But I also see your usecase more
as exception rather than the rule. And I am generally quite reluctant to make
concessions to special cases, at least when they might impede standard usage.
Maybe a quick custom hack like discussed here solves your requirement? [404, Invalid URL: https://sourceforge.net/tracker/?func=detail&%3Baid=2887039&%3Bgroup_id=234430&%3Batid=1093083]
> Tip: do you know Backer? Backer works the way i'm saying, it's a
different app but you
> can try it just to see and take ideas from that.
No. Thanks I'll have a look at it!
- Posts: 2
- Joined: 28 Feb 2006
Love the program - it's faster and more complete in many ways that similar
products (like microsoft's synctoy... dodgy prog. that.).
I do see what Nuno is saying though, giving the user more control (in a
simplistic way - all users are used to save as dialogues) eases some of the
issues with finding a file. If a user is not savvy enough to figure out where
a config file should go, then they are also quite likely to delete the file in
their directories being synced.
This doesn't necessarily have to be complex - asking the user to name their
configuation (which they have to do anyway) can then be used to create the
sync database and the other file - i.e. save it under their name, which
makes sense to them. You could for simplicity's sake then save it in the
application directory (or a sub-folder) or for better security, in the user's
(windows) application data folder (eg. c:\documents and
settings\%username%\application data\freefilesync\). Easy, little mess, and
all those details (in Windows anyway) are easily picked up through MS api's.
No more mess with GUI, no more actions required of the user, just the
programmer.
Anyway, that's my 2 cents worth.
Richard.
products (like microsoft's synctoy... dodgy prog. that.).
I do see what Nuno is saying though, giving the user more control (in a
simplistic way - all users are used to save as dialogues) eases some of the
issues with finding a file. If a user is not savvy enough to figure out where
a config file should go, then they are also quite likely to delete the file in
their directories being synced.
This doesn't necessarily have to be complex - asking the user to name their
configuation (which they have to do anyway) can then be used to create the
sync database and the other file - i.e. save it under their name, which
makes sense to them. You could for simplicity's sake then save it in the
application directory (or a sub-folder) or for better security, in the user's
(windows) application data folder (eg. c:\documents and
settings\%username%\application data\freefilesync\). Easy, little mess, and
all those details (in Windows anyway) are easily picked up through MS api's.
No more mess with GUI, no more actions required of the user, just the
programmer.
Anyway, that's my 2 cents worth.
Richard.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
I have to admit that I didn't like the idea of having a database file at first
neither. Just as Nuno I also despise usage of those little dummy files like
desktop.ini and thumbs.db. But thinking about all implications, saving it
directly in sync-dir offers a number of advantages (as discussed) by design.
The only drawback that I see is having this additional file in the sync-
directory. I consider this the "price" for these advantages.
The other suggestions like saving it in installation directory are less
flexible, i.e. don't work when users have multiple FFS-installations on
different PCs sync via USB, or always use the standard (LastRun.ffs_gui)
configuration file. Also introduce new risks, e.g. when syncing against
variable drives (e.g. USB), because the program cannot distinguish wheter it
is another USB stick or if just data changed.
There is actually quite a lot to be considered as you see (and probably is
more) and I definitively didn't make it a quick and easy decision.
neither. Just as Nuno I also despise usage of those little dummy files like
desktop.ini and thumbs.db. But thinking about all implications, saving it
directly in sync-dir offers a number of advantages (as discussed) by design.
The only drawback that I see is having this additional file in the sync-
directory. I consider this the "price" for these advantages.
The other suggestions like saving it in installation directory are less
flexible, i.e. don't work when users have multiple FFS-installations on
different PCs sync via USB, or always use the standard (LastRun.ffs_gui)
configuration file. Also introduce new risks, e.g. when syncing against
variable drives (e.g. USB), because the program cannot distinguish wheter it
is another USB stick or if just data changed.
There is actually quite a lot to be considered as you see (and probably is
more) and I definitively didn't make it a quick and easy decision.
- Posts: 20
- Joined: 5 Dec 2005
Great, it seams that you have thought in everything.
But, can you think about this option? What about creating an option for the
user to choose the way he would like to do?
Then this would fit to everyone.
Just the option to save the database with the same name and in the same
location we save the configuration.
Thanks
Nuno Leite
: http://www.nunoleite.com
But, can you think about this option? What about creating an option for the
user to choose the way he would like to do?
Then this would fit to everyone.
Just the option to save the database with the same name and in the same
location we save the configuration.
Thanks
Nuno Leite
: http://www.nunoleite.com
- Posts: 2
- Joined: 28 Feb 2006
I'm actually going to have to agree with Zenju here - less options to confuse
the user on the main gui. Could there be an advanced option though? I'm
thinking that for the tinkers out there, we could have advanced customisation
of things like this.
Otherwise, we could always look at the code and build it in for ourselves...
Yay Open Source!
the user on the main gui. Could there be an advanced option though? I'm
thinking that for the tinkers out there, we could have advanced customisation
of things like this.
Otherwise, we could always look at the code and build it in for ourselves...
Yay Open Source!
- Posts: 20
- Joined: 5 Dec 2005
I agree with the advanced options.
And of course, Open Source Rules.........
Thanks
Nuno Leite
: http://www.nunoleite.com
And of course, Open Source Rules.........
Thanks
Nuno Leite
: http://www.nunoleite.com
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
An advanced option to specify a sync-database would be okay with me. But
unfortunately such a feature is no "quick-win": it's a completely
new design, let's get more into detail:
Currently there is a database file in each to-be-synced directories. It serves
two purposes.
1. needed to detect data changes
2. an identifier to uniquely specify a physical "data-source". This is unique, no matter if directory name changes, drive letter changes, or different installations of FFS access it.
Point 2 would need to be dropped, which I consider a main drawback of having a
fixed path to sync-database.
But anyway, let's think this through, so I assume the user is aware of this or
simply doesn't need this feature, because he manages the database-file
himself.
With this adv. option we'd have only one db-file (easily identified by a new
config. path) per configuration. This file would need to store, db-entries for
each folder-pair (consider multi-FP-usage). These would need to be maintained
correctly, i.e., when a folder pair is removed, the two corresponding db-
entries would need to be removed, when a folder pair is added, two new entries
are added, changing of a directory name => adapt db-entry (delete/create
new one). Temporarily changing target path back and forth => db-entry gets
invalidated (because db-entry is now bound by name, and not by physical
location(!)), support for relative directory names becomes
difficult/unmanageable. Having multiple configurations that use the same
folderpairs introduces ambiguity, but would be technically possible.
This opens up for considerable maintenance work that needs to be done
consistently and correctly as well as functional regression at some subtle
places. With the current design, there is none of these problems at all.
Sum up: Offering an advanced option is no simple "provide alternate path
and be good" thing. It entails considerable changes at design level and
introduces new risks that the current design avoids.
unfortunately such a feature is no "quick-win": it's a completely
new design, let's get more into detail:
Currently there is a database file in each to-be-synced directories. It serves
two purposes.
1. needed to detect data changes
2. an identifier to uniquely specify a physical "data-source". This is unique, no matter if directory name changes, drive letter changes, or different installations of FFS access it.
Point 2 would need to be dropped, which I consider a main drawback of having a
fixed path to sync-database.
But anyway, let's think this through, so I assume the user is aware of this or
simply doesn't need this feature, because he manages the database-file
himself.
With this adv. option we'd have only one db-file (easily identified by a new
config. path) per configuration. This file would need to store, db-entries for
each folder-pair (consider multi-FP-usage). These would need to be maintained
correctly, i.e., when a folder pair is removed, the two corresponding db-
entries would need to be removed, when a folder pair is added, two new entries
are added, changing of a directory name => adapt db-entry (delete/create
new one). Temporarily changing target path back and forth => db-entry gets
invalidated (because db-entry is now bound by name, and not by physical
location(!)), support for relative directory names becomes
difficult/unmanageable. Having multiple configurations that use the same
folderpairs introduces ambiguity, but would be technically possible.
This opens up for considerable maintenance work that needs to be done
consistently and correctly as well as functional regression at some subtle
places. With the current design, there is none of these problems at all.
Sum up: Offering an advanced option is no simple "provide alternate path
and be good" thing. It entails considerable changes at design level and
introduces new risks that the current design avoids.
- Posts: 20
- Joined: 5 Dec 2005
I totally agree with you Zenju.
Seeing things like that, it seems that you choose the right way.
keep up the great work, and let's what the future brings.
To be honest i really don't think i will use this feature. Only just in a
special situation when it would be the only way. Just in a situation when it
would be needed to work in two places at the same time, and as to be done a
Full synchronization with reflection of deletions would be needed.
The strongest part of this application is really the simplicity and the dual
pane when we can compare and decide everything in just 1 window.
My main usage will be, to do a 1 direction only mirror or update to make my
backups, and for this, this application is excellent.
NOTE: i really have to put this on my website and create an article about it,
to help my users in making their backups easier. Every one i show this
application liked it and started using immediately.
Thanks, and keep it going.
Nuno Leite
: http://www.nunoleite.com
Seeing things like that, it seems that you choose the right way.
keep up the great work, and let's what the future brings.
To be honest i really don't think i will use this feature. Only just in a
special situation when it would be the only way. Just in a situation when it
would be needed to work in two places at the same time, and as to be done a
Full synchronization with reflection of deletions would be needed.
The strongest part of this application is really the simplicity and the dual
pane when we can compare and decide everything in just 1 window.
My main usage will be, to do a 1 direction only mirror or update to make my
backups, and for this, this application is excellent.
NOTE: i really have to put this on my website and create an article about it,
to help my users in making their backups easier. Every one i show this
application liked it and started using immediately.
Thanks, and keep it going.
Nuno Leite
: http://www.nunoleite.com
