Is there a way to tell FFS to not update/write to LastRun.ffs_gui and
GlobalSettings.xml? Or auto-clear the FolderPairs? Or perhaps kill the error
message if the files are set to read only? Sometimes it's desirable to start
with a known configuration, especially when working from a flash drive or CD.
Don't update LastRun and GlobalSetting?
- Posts: 7
- Joined: 5 Mar 2010
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
> clear the FolderPairs?
Menu -> file -> new
> just starting with a known configuration
Double click on a preconfigured *.ffs_gui file
What is the specific usecase you're trying to fulfill?
Menu -> file -> new
> just starting with a known configuration
Double click on a preconfigured *.ffs_gui file
What is the specific usecase you're trying to fulfill?
- Posts: 7
- Joined: 5 Mar 2010
Thanks for your reply. I prefer apps to work in true stealth mode and not
write anything to the usb drive. I set things up so every time I start an app
I know it's starting from an exact 'default' state. Then, I can change things
as needed when the app is open, knowing that the next time I start things up
it'll be from this default state. Is there a reason that the previous
settings/history HAVE to be written to those files?
write anything to the usb drive. I set things up so every time I start an app
I know it's starting from an exact 'default' state. Then, I can change things
as needed when the app is open, knowing that the next time I start things up
it'll be from this default state. Is there a reason that the previous
settings/history HAVE to be written to those files?
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
> reason that the previous settings/history HAVE to be written
As for "LastRun.ffs_gui" it's mostly for convenience to remember last sync
configuration. So arguably it would not be such a big loss of information, if
this file was not written. With GlobalSettings.xml its a bit different. It
contains all the global settings, so not writing it definitively would be a
loss of information. (But an optimization could be to only write it, if
settings actually have changed. Currently it's always written.)
The main problem is how detect whether these files should be written or not.
As for "LastRun.ffs_gui" it's mostly for convenience to remember last sync
configuration. So arguably it would not be such a big loss of information, if
this file was not written. With GlobalSettings.xml its a bit different. It
contains all the global settings, so not writing it definitively would be a
loss of information. (But an optimization could be to only write it, if
settings actually have changed. Currently it's always written.)
The main problem is how detect whether these files should be written or not.
- Posts: 7
- Joined: 5 Mar 2010
What about an option under 'File' (or in GlobalSettings.xml) to the effect ..
"Update config on exit" ? Leave it checked and everything remains as it is
now. Uncheck it and NOTHING is saved at close. As it is now, I have set the
files to R/O, but I get four annoying error messages telling me the files
couldn't be updated. Everything still works as it should the next time I start
it.
"Update config on exit" ? Leave it checked and everything remains as it is
now. Uncheck it and NOTHING is saved at close. As it is now, I have set the
files to R/O, but I get four annoying error messages telling me the files
couldn't be updated. Everything still works as it should the next time I start
it.
-
- Site Admin
- Posts: 7058
- Joined: 9 Dec 2007
>What about an option
Well, an 'option' basically is not an option. (Sorry for the pun ;) The
underlying concept of the tool is to maximize ease-of-use by provinding only
necessary functionality on GUI, including the settings dialogs.
>four annoying error
Although these messages are not supposed to be seen in first place, having two
error messages indicate each single error situation clearly is too much (there
have been reasons for this behavior, though). Anyway I've written my own file
I/O functionality, which reduces the number of messages to two in total and
gives a better error description.
Well, an 'option' basically is not an option. (Sorry for the pun ;) The
underlying concept of the tool is to maximize ease-of-use by provinding only
necessary functionality on GUI, including the settings dialogs.
>four annoying error
Although these messages are not supposed to be seen in first place, having two
error messages indicate each single error situation clearly is too much (there
have been reasons for this behavior, though). Anyway I've written my own file
I/O functionality, which reduces the number of messages to two in total and
gives a better error description.
