Hello Zen,
First, thanks for a great program! I've recommended it to all my friends &
associates. I've a bug report and a suggestion for improvement. I hope you
will consider them.
Bug: I'm using v3.3 portable configuration. I've placed FFS files in the
system path (per SET PATH command). When invoked, FFS doesn't find its xml
config file, and use the original default setup. What should happen is that
FFS should look in the directory where the executable resides for its config &
support files, not the current directory.
Suggestion: Instead of the workaround for the variable drive letters that USB
drives are sometimes assigned, I've a better solution: Allow FFS to look for a
'signature' file in the target directory, by browsing all the drives, and
using the specified path. If sig file is found then target drive is
determined. This creates drive independence.
Example:
I want to sync C:\Videos\DailyPodcasts\ to a USB drive folder at \BK\. I
create a 0-byte signature file, Daily_Podcasts.ffs, in the target folder on
USB drive. I tell FFS the path, and the sig file to look for:
\BK\Daily_Podcasts.ffs. When invoked, FFS searches all the drives starting
with A: for the specified path and sig file. Once found, it places the sync in
the found location.
Again, I very much appreciate your work and your sharing it with us.
Bug: FFS can't locate its config file
- Posts: 3
- Joined: 8 Feb 2010
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
Hi emote,
> Bug:
Currently this is the functionality of the portable version. FFS comes in two
flavors: 1. portable 2. local. Former saves and loads default-config data from
current working directory while latter uses %appdata%\FreeFileSync.
There are two usecases that require this logic for portable mode:
1. Starting sync from a read-only USB-stick because of paranoia that viruses on the local PC could infiltrate the stick.
2. Using multiple versions of global configuration data (GlobalSettings.xml / LastRun.ffs_gui) because some other granularity of config is needed than I have anticipated.
The actual implementation fulfills both requirements, but has the disadvantage
that users need to take care for their current working directory when
starthing the (portable) tool.
> Suggestion:
I'm not sure what exactly the advantage is of having a signature file compared
to using a fixed drive or relative paths. Both methods provide some means to
sync against a USB stick without requiring a fixed volume name, but former
requires additional handling of this "signature file".
Regards, Zenju
> Bug:
Currently this is the functionality of the portable version. FFS comes in two
flavors: 1. portable 2. local. Former saves and loads default-config data from
current working directory while latter uses %appdata%\FreeFileSync.
There are two usecases that require this logic for portable mode:
1. Starting sync from a read-only USB-stick because of paranoia that viruses on the local PC could infiltrate the stick.
2. Using multiple versions of global configuration data (GlobalSettings.xml / LastRun.ffs_gui) because some other granularity of config is needed than I have anticipated.
The actual implementation fulfills both requirements, but has the disadvantage
that users need to take care for their current working directory when
starthing the (portable) tool.
> Suggestion:
I'm not sure what exactly the advantage is of having a signature file compared
to using a fixed drive or relative paths. Both methods provide some means to
sync against a USB stick without requiring a fixed volume name, but former
requires additional handling of this "signature file".
Regards, Zenju
- Posts: 3
- Joined: 8 Feb 2010
Zenju,
Re: FFS not finding its config file - The philosophy of having a portable app
is to leave no footprint on the host PC. Most every portable apps I've use
(i.e. those that use accompanying config files) have always followed this
tenet, no matter where they are in the system path. The requirement of needing
a shortcut link, or having to be in the app's current folder upon invocation,
violates this philosophy, IMO, as is the practice of dropping multiple config
files all over the system. In its current incarnation, I'm not sure how one
can qualify FFS as a 'portable' app.
Re: Sig file for location determination - Again, I'm following the "no
footprint" tenet above. The workaround suggested in the help file would have
different config files in the root directory of each (USB) backup drive. With
a sig file, such 'app droppings' can be avoided, and all config files can
simply be placed with the executable rather than be scattered. In the old DOS
days, the 'ifexist..do' batch command accomplishes this. I'm hoping for the
same functionality from FFS.
Thanks again for your consideration.
Re: FFS not finding its config file - The philosophy of having a portable app
is to leave no footprint on the host PC. Most every portable apps I've use
(i.e. those that use accompanying config files) have always followed this
tenet, no matter where they are in the system path. The requirement of needing
a shortcut link, or having to be in the app's current folder upon invocation,
violates this philosophy, IMO, as is the practice of dropping multiple config
files all over the system. In its current incarnation, I'm not sure how one
can qualify FFS as a 'portable' app.
Re: Sig file for location determination - Again, I'm following the "no
footprint" tenet above. The workaround suggested in the help file would have
different config files in the root directory of each (USB) backup drive. With
a sig file, such 'app droppings' can be avoided, and all config files can
simply be placed with the executable rather than be scattered. In the old DOS
days, the 'ifexist..do' batch command accomplishes this. I'm hoping for the
same functionality from FFS.
Thanks again for your consideration.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> Re1:
Maybe FFS needs to support some commandline parameters after all, to specify a
directory to save configuration data. Your point concerning behavior of
"portable" is valid, of course, but the other usecases should be supported,
too.
Technically all requirements are fulfilled already, but it requires the user
to know the behavior of the tool when it comes to saving config data. So the
problem is mostly about user-friendliness here.
> Re2:
Config files need not be placed into each USB stick's root directory
redundantly. The approach about detecting the correct drive you describe can
be achieved by writing a appropriate batch file (*.cmd) that tests all drives
until it finds the one containing the relevant id-file. Generally I think this
usecase about finding the appropriate sync-directory automatically is rather
special, maybe too special to be handled by the tool.
Regards, Zenju
Maybe FFS needs to support some commandline parameters after all, to specify a
directory to save configuration data. Your point concerning behavior of
"portable" is valid, of course, but the other usecases should be supported,
too.
Technically all requirements are fulfilled already, but it requires the user
to know the behavior of the tool when it comes to saving config data. So the
problem is mostly about user-friendliness here.
> Re2:
Config files need not be placed into each USB stick's root directory
redundantly. The approach about detecting the correct drive you describe can
be achieved by writing a appropriate batch file (*.cmd) that tests all drives
until it finds the one containing the relevant id-file. Generally I think this
usecase about finding the appropriate sync-directory automatically is rather
special, maybe too special to be handled by the tool.
Regards, Zenju
- Posts: 3
- Joined: 8 Feb 2010
>Re1:
I'm curious of what justification exists for the app to deposit its config
files in whatever directory is current. By any measure, the app--portable or
no--should ask permission before depositing its config files in any location
other than the locations assigned to it, viz where the exe lies, or in one of
the \Documents & Settings locations. With due respect, I think this goes
beyond user-friendliness. It's something I would expect of a Microsoft app to
do, to dump its files willy-nilly all over the system. The other half of it
for the app to work correctly, I can only invoke it from where the exe lies,
not where the data to be synced is.
I'm not sure why there's a need for FFS to support commandline params to find
its config files. I am no programmer, but of the old console batch writing
tools, the ability to ascertain location of the invoked exe is a basic use,
and frequently called upon.
>Re2:
Yes, there exist plenty of workarounds, such as the 'if exist' cmd I've
mentioned. The point is that they are just that, workarounds to compensate for
the app's lack of ability to sync to a specified path regardless of drive
letter assignment. I don't see such as a 'special case' use, but a core
ability of a smart sync program.
Again, would ask that you reconsider. Thanks.
I'm curious of what justification exists for the app to deposit its config
files in whatever directory is current. By any measure, the app--portable or
no--should ask permission before depositing its config files in any location
other than the locations assigned to it, viz where the exe lies, or in one of
the \Documents & Settings locations. With due respect, I think this goes
beyond user-friendliness. It's something I would expect of a Microsoft app to
do, to dump its files willy-nilly all over the system. The other half of it
for the app to work correctly, I can only invoke it from where the exe lies,
not where the data to be synced is.
I'm not sure why there's a need for FFS to support commandline params to find
its config files. I am no programmer, but of the old console batch writing
tools, the ability to ascertain location of the invoked exe is a basic use,
and frequently called upon.
>Re2:
Yes, there exist plenty of workarounds, such as the 'if exist' cmd I've
mentioned. The point is that they are just that, workarounds to compensate for
the app's lack of ability to sync to a specified path regardless of drive
letter assignment. I don't see such as a 'special case' use, but a core
ability of a smart sync program.
Again, would ask that you reconsider. Thanks.
-
- Site Admin
- Posts: 7210
- Joined: 9 Dec 2007
> I'm not sure why there's a need for FFS to support commandline params
Technically it's no problem to have all configuration saved in the directory
where the executable residers. This is purely a design question here,
especially the two requirements mentioned above should be covered somehow.
> but a core ability of a smart sync program.
Is there some other sync program that does this? I'd like to have a look at
its design.
Technically it's no problem to have all configuration saved in the directory
where the executable residers. This is purely a design question here,
especially the two requirements mentioned above should be covered somehow.
> but a core ability of a smart sync program.
Is there some other sync program that does this? I'd like to have a look at
its design.
