Running the latest v.3.10 I've noticed:
1. It's hard to read black font on dark gray background (default theme).
2. It's hard to work with 10 synchronized folders at the time when you can see only one of them...
Look at the picture:
[404, Invalid URL: http://img684.imageshack.us/img684/8996/ffs310listoffolders.png]
The list of my folders (10 of them) now is shrunk to just one row. It becomes
extremely inconvenient to manage the list.
And second, as you can see, the first line contains two empty dummy local
folders (A1 and A2) that I have to keep as a main folder(s). I don't need any
main folder. All my folders that I want to synchronize have to be configured
individually. In other words, I have a group of folders where there is no any
main folder.
Can I remove the dummy folders (A1 and A2) and keep just only folders that I
need to synchronize?
3. Now v.3.10 shows a lot of files that differ only in 1 hour in their tame stamps (obviously due to DST shift). I have to check all of them manually and remove one by one from the list...
How to work with the DST if both local and removed FSs are NTFS?
Running v.3.10
- Posts: 34
- Joined: 15 Sep 2009
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> 1. It's hard to read black font on dark gray background (default theme).
See: http://msdn.microsoft.com/en-us/library/ms531197%28VS.85%29.aspx
Old value was "InactiveCaption" which was not correct and resulted in dark
blue background color on some systems. For v3.10 I changed to "AppWorkspace"
which looks perfect on my machines (Win7, Ubuntu, XP-SP3) but is too dark on
others. For v3.11 I'll change to "Menu". Hopefully that's the one-serves-all
solution...
> 2. It's hard to work with
Clearly a migration bug. I'll release a fixed v3.11 for this. Nevertheless
you'll have to delete GlobalSettings.xml to reset the maximum number of
visible folder pairs.
>3. Now v.3.10 shows a lot of files that differ only in 1 hour
This is one-time migration step. The files that you're seing are the ones that
have been suppressed by the "+-1h switch". In future file time will be
calculated correctly, so forcing different file-times to be seen as equal is
not needed anymore.
> How to work with the DST if both local and removed FSs are NTFS?
DST issues occur only between FAT and non-FAT filesystems.
See: http://msdn.microsoft.com/en-us/library/ms531197%28VS.85%29.aspx
Old value was "InactiveCaption" which was not correct and resulted in dark
blue background color on some systems. For v3.10 I changed to "AppWorkspace"
which looks perfect on my machines (Win7, Ubuntu, XP-SP3) but is too dark on
others. For v3.11 I'll change to "Menu". Hopefully that's the one-serves-all
solution...
> 2. It's hard to work with
Clearly a migration bug. I'll release a fixed v3.11 for this. Nevertheless
you'll have to delete GlobalSettings.xml to reset the maximum number of
visible folder pairs.
>3. Now v.3.10 shows a lot of files that differ only in 1 hour
This is one-time migration step. The files that you're seing are the ones that
have been suppressed by the "+-1h switch". In future file time will be
calculated correctly, so forcing different file-times to be seen as equal is
not needed anymore.
> How to work with the DST if both local and removed FSs are NTFS?
DST issues occur only between FAT and non-FAT filesystems.
- Posts: 34
- Joined: 15 Sep 2009
> For v3.11 I'll change to "Menu". Hopefully that's the one-serves-all
solution...
Thanks. That's what I see in WXP: [404, Invalid URL: http://img684.imageshack.us/img684/9855/ffscolortheme.png]
BTW, dialog on this picture asks: "Do you want ...". The expected answers are:
"Yes", "No". The provided answer "Cancel" is a bit confusing... It's not a big
deal, of cause.
> Nevertheless you'll have to delete GlobalSettings.xml to reset the maximum
number of visible folder pairs.
That helps. But it removed all my customized settings in the process too. I've
reverted that back and just changed the FolderPairsMax to old value.
> This is one-time migration step.
> DST issues occur only between FAT and non-FAT filesystems.
But that is what occurs right now with NTFS on both sides. That's why I was
asking.
Should I allow to overwrite all those files with new time stamps now or I
should wait for a new release?
solution...
Thanks. That's what I see in WXP: [404, Invalid URL: http://img684.imageshack.us/img684/9855/ffscolortheme.png]
BTW, dialog on this picture asks: "Do you want ...". The expected answers are:
"Yes", "No". The provided answer "Cancel" is a bit confusing... It's not a big
deal, of cause.
> Nevertheless you'll have to delete GlobalSettings.xml to reset the maximum
number of visible folder pairs.
That helps. But it removed all my customized settings in the process too. I've
reverted that back and just changed the FolderPairsMax to old value.
> This is one-time migration step.
> DST issues occur only between FAT and non-FAT filesystems.
But that is what occurs right now with NTFS on both sides. That's why I was
asking.
Should I allow to overwrite all those files with new time stamps now or I
should wait for a new release?
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> Thanks. That's what I see in WXP
In v3.11 the background color is much brighter, so this should be fine now.
> "Cancel" is a bit confusing
"cancel" ususally has the semantics of "just quit this action no matter what
you are trying to do" which is a safe way to abort something without
necessarily having to read all detailed instructions. My expectation was that
this decision can be made quicker than having to read everything and then say
"No", even if "no" is the more appropriate answer.
>Should I allow to overwrite all those files with new time stamps now
Yes. The actual root of this time shift is FAT-'NTFS file time handling which
has been solved. So a situation like above shouln't occur anymore.
In v3.11 the background color is much brighter, so this should be fine now.
> "Cancel" is a bit confusing
"cancel" ususally has the semantics of "just quit this action no matter what
you are trying to do" which is a safe way to abort something without
necessarily having to read all detailed instructions. My expectation was that
this decision can be made quicker than having to read everything and then say
"No", even if "no" is the more appropriate answer.
>Should I allow to overwrite all those files with new time stamps now
Yes. The actual root of this time shift is FAT-'NTFS file time handling which
has been solved. So a situation like above shouln't occur anymore.
- Posts: 34
- Joined: 15 Sep 2009
You're right. Dialog box can have "Yes" and "No" buttons. They require user to
make explicit decision. If there is a third "Cancel" button - the user has a
chance to postpone that decision, by canceling the whole action, asking for
that decision. Example - you close editor, that has opened files. It may
prompt you: "Do you want to save the file?" with set of options: "Yes", "No"
and "Cancel". Where the latter will cancel the action of closing the editor
(so, actual decision to save file or not is postponed).
If you want - you may have those 3 buttons on the dialog boxes too. Where the
"Cancel" button has the same meaning - postpone the decision. But using the
"Cancel" as substitute for "No" is a bit confusing though.
Thanks for the prompt fix in v3.11 :)
Here is one more small problem that I see. It happens, that my two dummy
folders representing the "main" folder pair (A1 and A2), are within one of the
common folder pairs and that pair always tries to copy files "sync.ffs_lock"
from one (A1) to another subfolder (A2). I always delete them manually, but it
takes my time... It looks like the whole idea around those lock files creates
more trouble for me, then offers any benefit.
make explicit decision. If there is a third "Cancel" button - the user has a
chance to postpone that decision, by canceling the whole action, asking for
that decision. Example - you close editor, that has opened files. It may
prompt you: "Do you want to save the file?" with set of options: "Yes", "No"
and "Cancel". Where the latter will cancel the action of closing the editor
(so, actual decision to save file or not is postponed).
If you want - you may have those 3 buttons on the dialog boxes too. Where the
"Cancel" button has the same meaning - postpone the decision. But using the
"Cancel" as substitute for "No" is a bit confusing though.
Thanks for the prompt fix in v3.11 :)
Here is one more small problem that I see. It happens, that my two dummy
folders representing the "main" folder pair (A1 and A2), are within one of the
common folder pairs and that pair always tries to copy files "sync.ffs_lock"
from one (A1) to another subfolder (A2). I always delete them manually, but it
takes my time... It looks like the whole idea around those lock files creates
more trouble for me, then offers any benefit.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> If there is a third "Cancel" button - the user has a chance to postpone that
decision
Then we'd have "Yes, No, Cancel" in total. Seeing this in practice it looks
way too wordy for this not-so-important question. So two buttons must suffice
and I'll stick with "Yes, No" because these are the two action that are
currently implemented, albeit "no" being mislabled as "cancel.
>Thanks for the prompt fix in v3.11 :)
Thank you for the report! Although it was a migration issue "only" it's
consequence was a real showstopper for multi-folder-pair syncs.
> It looks like the whole idea around those lock files creates more trouble
Don't give up yet. Your feedback concerning lock handling on program crash (or
more precisely the user killing the program) was precious and led to the
improved abandoned lock handling as implemented in v3.10. The problem
described above is also solvable: Locks shouldn't participate in
synchronization anyway. Currently they are only excluded from base
directories, because this is the place where they are expected. Having locks
in subdirectories beyond, looks esoteric to me, but seems to actually happen.
But first: What do you mean with dummy folders and what is their use?
decision
Then we'd have "Yes, No, Cancel" in total. Seeing this in practice it looks
way too wordy for this not-so-important question. So two buttons must suffice
and I'll stick with "Yes, No" because these are the two action that are
currently implemented, albeit "no" being mislabled as "cancel.
>Thanks for the prompt fix in v3.11 :)
Thank you for the report! Although it was a migration issue "only" it's
consequence was a real showstopper for multi-folder-pair syncs.
> It looks like the whole idea around those lock files creates more trouble
Don't give up yet. Your feedback concerning lock handling on program crash (or
more precisely the user killing the program) was precious and led to the
improved abandoned lock handling as implemented in v3.10. The problem
described above is also solvable: Locks shouldn't participate in
synchronization anyway. Currently they are only excluded from base
directories, because this is the place where they are expected. Having locks
in subdirectories beyond, looks esoteric to me, but seems to actually happen.
But first: What do you mean with dummy folders and what is their use?
- Posts: 34
- Joined: 15 Sep 2009
Thank you for some kind words.
With regard to the dummy folders (A1 and A2) I guess I was thinking in
yesterday's terms. Those folders were created and used in profile since there
was difference between main folder's pair (and I used those two empty folders
as that pair) and the rest (the rest had <AlternateFilter> tags at that time).
Now I think they all are equal (all use <LocalFilter> tags) and there is no
any difference in handling between the 1st pair and the rest (except in GUI,
displaying them slightly differently). Thus there is no any sense to keep
those folders at all and I've removed them from the profile. Thanks.
BTW, is there any reason why you don't want to follow the convention of naming
lock files? For example, GPG creates file "trustdb.gpg.lock". KeePass uses
file "aName.kdb.lock". And you may use something like this: "sync.ffs.lock".
With regard to the dummy folders (A1 and A2) I guess I was thinking in
yesterday's terms. Those folders were created and used in profile since there
was difference between main folder's pair (and I used those two empty folders
as that pair) and the rest (the rest had <AlternateFilter> tags at that time).
Now I think they all are equal (all use <LocalFilter> tags) and there is no
any difference in handling between the 1st pair and the rest (except in GUI,
displaying them slightly differently). Thus there is no any sense to keep
those folders at all and I've removed them from the profile. Thanks.
BTW, is there any reason why you don't want to follow the convention of naming
lock files? For example, GPG creates file "trustdb.gpg.lock". KeePass uses
file "aName.kdb.lock". And you may use something like this: "sync.ffs.lock".
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Just implemented this feature for v3.12:
Automatically exclude database and lock files from all directories (not only
from base)
> reason why you don't want to follow the convention of naming lock files?
Basically two reasons: 1. Consistency with *.ffs_gui, *.ffs_batch, *.ffs_real,
*.ffs_tmp, *.ffs_db 2. FFS Lock files are automatically excluded during
traversal. Therefore I need a FFS specific identifier.
Automatically exclude database and lock files from all directories (not only
from base)
> reason why you don't want to follow the convention of naming lock files?
Basically two reasons: 1. Consistency with *.ffs_gui, *.ffs_batch, *.ffs_real,
*.ffs_tmp, *.ffs_db 2. FFS Lock files are automatically excluded during
traversal. Therefore I need a FFS specific identifier.
