I use this app with great pleasure. I just dumped into one thing which is less
logical to me:
When you click on the filter button you get a window which says: "Global
Filter". But this appears to be not a global filter but a filter which is
stored in the local config file (the ffs_gui file). This means, that if you
use different ffs.gui settings in config files, the filter settings are not
global (like the global settings), but only applicable in the current ffs_gui
file.
I thinks the text in the filter window might not be good because of this (but
maybe I am wrong). But more importantly: isn't there a bigger need for the
file filters to be real global instead of stored in the ffs_gui config files.
I think many users may want to set specific global filters, applicable for all
config files (ffs_gui files). I personally always put:
*Thumbs.db
*.ffs_db
in there, since these are normally files that better not be synchronized. I
have to add this to all my ffs_gui files. It may be better for most users to
have those filters acting really global (or maybe have both....?)
Global vs local filters
- Posts: 8
- Joined: 27 Nov 2009
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
>but only applicable in the current ffs_gui file.
You're right, this is indeed ambiguous: "Global" is meant here in the sense of
being applicable to more than one folder pair, while "local" applies to one
folder pair only.
I should just rename it to something like "Filter all pairs" and "Filter
single pair". This will make things clear.
>I personally always put: *.ffs_db
For FreeFileSync this shouldn't be necessary. The DB-files are already
excluded from synchronization base directories automatically.
> to have those filters acting really global (or maybe have both....?)
The filter names always need to be relative to base synchronization
directories. Therefore they cannot be "config-global" (= apply to all
configurations) because they each depend from a specific folder pair: e.g.
Exclude: "\Subdir"
Your example (*Thumbs.db) is an exception, because the filter starts with a
'*', thous could be made "cfg-global". But for other filters this is not
possible.
You're right, this is indeed ambiguous: "Global" is meant here in the sense of
being applicable to more than one folder pair, while "local" applies to one
folder pair only.
I should just rename it to something like "Filter all pairs" and "Filter
single pair". This will make things clear.
>I personally always put: *.ffs_db
For FreeFileSync this shouldn't be necessary. The DB-files are already
excluded from synchronization base directories automatically.
> to have those filters acting really global (or maybe have both....?)
The filter names always need to be relative to base synchronization
directories. Therefore they cannot be "config-global" (= apply to all
configurations) because they each depend from a specific folder pair: e.g.
Exclude: "\Subdir"
Your example (*Thumbs.db) is an exception, because the filter starts with a
'*', thous could be made "cfg-global". But for other filters this is not
possible.
- Posts: 8
- Joined: 27 Nov 2009
>I should just rename it to something like "Filter all pairs" and "Filter
single pair". This will make things clear.
This would indeed inprove clarity for some people (which have the same habbit
of misreading things as I have ;-) ).
>>I personally always put: *.ffs_db
>For FreeFileSync this shouldn't be necessary. The DB-files are already
excluded from synchronization base directories automatically.
Hmmm, this is stange. I kept getting conflict sync status icons after
comparing for those files when I didn't have this filter configured like this.
Yes, with FreeFileSync. How is that possible if they are always excluded?
>> to have those filters acting really global (or maybe have both....?)
>The filter names always need to be relative to base synchronization
directories. Therefore they cannot be "config-global" (= apply to all
configurations) because they each depend from a specific folder pair: e.g.
Exclude: "\Subdir"
Your example (*Thumbs.db) is an exception, because the filter starts with a
'*', thous could be made "cfg-global". But for other filters this is not
possible.
This remark seems to be in conflict with your answer to the first point. If
this is not possible for different base dirs because it are relative paths,
then why is it possible for different folder pairs (which also have different
relative paths). Probably I miss something.
single pair". This will make things clear.
This would indeed inprove clarity for some people (which have the same habbit
of misreading things as I have ;-) ).
>>I personally always put: *.ffs_db
>For FreeFileSync this shouldn't be necessary. The DB-files are already
excluded from synchronization base directories automatically.
Hmmm, this is stange. I kept getting conflict sync status icons after
comparing for those files when I didn't have this filter configured like this.
Yes, with FreeFileSync. How is that possible if they are always excluded?
>> to have those filters acting really global (or maybe have both....?)
>The filter names always need to be relative to base synchronization
directories. Therefore they cannot be "config-global" (= apply to all
configurations) because they each depend from a specific folder pair: e.g.
Exclude: "\Subdir"
Your example (*Thumbs.db) is an exception, because the filter starts with a
'*', thous could be made "cfg-global". But for other filters this is not
possible.
This remark seems to be in conflict with your answer to the first point. If
this is not possible for different base dirs because it are relative paths,
then why is it possible for different folder pairs (which also have different
relative paths). Probably I miss something.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
>Hmmm, this is stange. I kept getting conflict sync status icons after
comparing for those files
Are the db files visible on the screen after comparison? They should not be
visible and therefore need not be excluded manually.
> If this is not possible for different base dirs because it are relative
paths, then why is it possible for different folder pairs
It's not that it's not possible, but merely that it doesn't make much sense.
The "global" filter that applies for multiple folder pairs also suffers from
the problem that it's use is limited to special filters like "*.tmp, *.lnk"
but not to relative filter paths.
But in contrast to a potential overall-global filter that would be applied to
every configuration, the actually implemented global filter applies only to a
single configuration. Therefore it's uncritical to change it, while a overall-
global filter (like any global setting) actually changes all other
configurations potentially in unsuspected ways. Thous I avoid such implicit
behavior at the cost of some convenience that on the other hand is almost
completely covered by the already implemented global filter setting.
comparing for those files
Are the db files visible on the screen after comparison? They should not be
visible and therefore need not be excluded manually.
> If this is not possible for different base dirs because it are relative
paths, then why is it possible for different folder pairs
It's not that it's not possible, but merely that it doesn't make much sense.
The "global" filter that applies for multiple folder pairs also suffers from
the problem that it's use is limited to special filters like "*.tmp, *.lnk"
but not to relative filter paths.
But in contrast to a potential overall-global filter that would be applied to
every configuration, the actually implemented global filter applies only to a
single configuration. Therefore it's uncritical to change it, while a overall-
global filter (like any global setting) actually changes all other
configurations potentially in unsuspected ways. Thous I avoid such implicit
behavior at the cost of some convenience that on the other hand is almost
completely covered by the already implemented global filter setting.
- Posts: 8
- Joined: 27 Nov 2009
>Are the db files visible on the screen after comparison? They should not be
visible......
Yes, they are. Sometimes, not always. ....??
About the global filter. I understand your point. Applying global settings is
always something that users should use carefull. I just though it might
improve some convenience for some users though. Like the thumb.db files,
probably many people would like to exclude always. And there may be more
examples.
visible......
Yes, they are. Sometimes, not always. ....??
About the global filter. I understand your point. Applying global settings is
always something that users should use carefull. I just though it might
improve some convenience for some users though. Like the thumb.db files,
probably many people would like to exclude always. And there may be more
examples.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
>Yes, they are. Sometimes, not always. ....??
With the newest version 3.6? In which situation does this occur and what db
files are visible?
With the newest version 3.6? In which situation does this occur and what db
files are visible?
