Application: FreeFileSync
Category: Utilities/Synchronization
Description: Folder Comparison and Synchronization.
Download FreeFileSync Portable v3.2 - Development Test 1 [2 MB download]
Release Notes:
Development Test 1 (2009-12-23):
- Fixed starting batch jobs via FreeFileSyncPortable.exe
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
That's fantastic news. FreeFileSync is a popular synco app. Good job
I believe John is the one to answer about the review process.
Altho I should probably post in the official website, but there is something really bothering me in FFS. Although the language is English but because my Windows is RTL, the whole application direction is RTL which is really annoying.
We don't need a reason to help people ~ Zidane
I was not aware of this RTL issue until today morning:
https://sourceforge.net/tracker/?func=detail&aid=2887638&group_id=234430...
I'll fix this and include translations for Hebrew and Arabic. Maybe this will help you, too.
You're doing it right. You package it up and post it in the beta forum. We'll have some of our members review it and it'll make it into the directory
Sometimes, the impossible can become possible, if you're awesome!
> We'll have some of our members review it and it'll make it into the directory
Great!
Alright, is there anything left for me to do?
I already have FreeFileSync installed in a directory called:
\PortableApps\FreeFileSync 3.1
I used your paf to install to a directory called:
\PortableApps\FreeFileSync
When I ran your new FreeFileSyncPortable.exe, it found the .ffs_gui from my existing installation, and when I tried to save a configuration, it wanted to save to the existing installation folder, instead of the new folder.
This tells me that you are retrieving the location of the .ffs_gui files from somewhere other than the GlobalSettings.xml file (which affects the portability of the software).
I like the FreeFileSync software and I'm very glad that you are trying to get this to work correctly. Thanks very much!
neutron1132 (at) usa (dot) com
I seem to recall that FreeFileSync used a registry key in HKCU. This could be backed up and restored by a launcher as we do with other apps. (I haven't tested it yet, I'm busy coding).
Sometimes, the impossible can become possible, if you're awesome!
That was the VERY early releases...
The portable version (:= .zip) doesn't need registry.
In the portable version FreeFileSync reads it's configuration from the current working directory (There are no other dependencies, at least that I would know of, like Registry, etc).
The starter I created (FreeFileSyncPortable.exe, programmed it myself, 'cause I don't know if there is 'an official' way to create these...) simply executes "App\FreeFileSync\FreeFileSync.exe" from whatever directory it is started in.
To differentiate between portable and installer version I have a "very pragmatic" solution: If the file "uninstall.exe" is available the tool assumes it is the installer-version and it reads it's data from %appdata". I assume you have this file in your other "assumed portable" FFS installation.
Are you having the launcher move the data files to and from the data directory or setting the working path to something in Data? All data must be in the Data directory. The App directory will usually be deleted by default by an upgrade (unless you tell the installer otherwise).
Sometimes, the impossible can become possible, if you're awesome!
I'm just setting the working directory to "Data" and then start the tool. In my tests all user-configuration data was correctly written to it. In the "App\FreeFileSync" directory there is just pure static program data.
Tried it again.
I looked in the registry and there are a handful of entries that match "freefile", going back to version 2.1, 3.0 and 3.1.
I deleted all of those registry entries.
I went back and launched FreeFileSyncPortable.
I clicked on the "Load Configuration" button.
It brought up the correct directory.
So, the program must first look at the registry, then into the current directory structure.
neutron1132 (at) usa (dot) com
That needs to be fixed, then. It needs to look at the portable settings entirely and ignore the registry.
Sometimes, the impossible can become possible, if you're awesome!
This is not done by the tool (directly). These registry keys are created implicitly by Win32-API Function SHBrowseForFolder with Style BIF_NEWDIALOGSTYLE, or less technically put: Any application that offers a "browse" button.
If that's the case, that is fine. I didn't realize that was the keys we were thinking about. As long as it's only the Windows functionality in terms of Open, Browse, etc, it's fine.
Sometimes, the impossible can become possible, if you're awesome!
*pfew* I shortly feared I would have to clean-up after Windows! That would have been some WORK!
I can appreciate that Windows makes some registry entries. That's OK. (And I've been using the program for a while, so obviously I don't have a problem with this.)
What I was reporting was that the "portable" program installed into a different location makes use of those existing registry entries instead of looking to the \Data directory.
This means that if someone came by with the program on a USB stick, and the program was already installed on the host computer, the config files used would be the ones that already exist on the host computer and not the ones on the USB stick.
The "portable" version needs to look to itself ONLY.
neutron1132 (at) usa (dot) com
This only affects browsing (aka loading a configuration). That's just a File Open command window. Would I be correct in guessing that the normal configuration file is inside Data and automatically used?♠
Sometimes, the impossible can become possible, if you're awesome!
In the standard version, all files are in the program's main directory. In the portable version, the \Data directory seems to be used for the .ffs_gui files. That's a good thing.
The .ffs_gui files are used when you want to save a particular configuration (left/right directories, and include/exclude lists) and then load that setup on subsequent program uses.
For regular program operation, these files don't have to be used at all.
neutron1132 (at) usa (dot) com
I just had a quick look at this and it looks pretty good for the most part (and doesn't put anything it shouldn't in the registry) but there are a few things. Barring maybe the first couple, I don't know how critical they are -
Anyway, perhaps I'm being too picky but if you would like these issues sorted out, consider this an offer of my services
> "GlobalSettings.xml" still contains absolute paths
I see two places with absolute paths:
"": These are paths entered by the user, so this should be okay
"": Theoretically config files can be located on different drives. So the absolute path information would be needed. But that's just a convenience function I don't consider that important.
> If Data folder is missing, app won't even start
I'll fix this
> No automatic language switching when used with PA.c Platform
What is this?
> "installer.ini" is superfluous at the moment
I've included two checks for app running during update. They're not needed?
> Package version is incorrect in "appinfo.ini"
What is a "correct" version?
> Working directory is set to Data and not Data\settings
Settings are FFS's only data, so a subdir technically is not needed.
> Too many formats in appicon.ico
What's the problem with that?
> Help file could be tidied up a little
In which way?
> consider this an offer of my services
Thank you!
OK
When the app is launched from the PA.c menu it can (should?) check an environment variable and automatically switch to the language the menu is set to. Requires a launcher.
Of course, you're launcher isn't sticking around until the app closes so the entries are correct. Apologies, my mistake. It could still use the languages section to narrow the choices down to ones the app supports though.
In this case I would have thought it would just be the same as your display version.
OK, it's just convention.
No problem, again it's just convention.
The version number isn't generally listed in the help file, use lower case for your subtitle, move your description to above the donation icon and include the generic 'portable specific' stuff.
Again, sorry for being so picky, especially the help stuff
Where's Patrick Patience when you need him?
It's pretty trivial to adjust the drive letter in config files for changes using the launcher. We have existing code in nearly all our launchers to do that. It won't affect files on other drives (which should be rare because the point of a portable app is to exist on one drive and move around).
Sometimes, the impossible can become possible, if you're awesome!
I've done an update and fixed most of the issues discussed:
http://sourceforge.net/projects/freefilesync/files/freefilesync/v3.1/Fre...
> When the app is launched from the PA.c menu it can (should?) check an
> environment variable and automatically switch to the language the menu is set
> to. Requires a launcher.
Currently, if no configuration files are found, the tool selects the Operating System's language per default. Can this logic be used?
> It's pretty trivial to adjust the drive letter in config files for changes using
> the launcher. We have existing code in nearly all our launchers to do that.
You mean this "AppnamePortable.exe"? Where can I get the sourcecode of one of them?
They're included with all our apps in the Other\Source directory. They're in NSIS. We can assist with it as needed.
Sometimes, the impossible can become possible, if you're awesome!
I've done yet another update, created language entries, added a custom launcher and included logic to handle variable drive letters in configuration files:
http://sourceforge.net/projects/freefilesync/files/freefilesync/v3.1/Fre...
Is there anything left that needs to be fixed?
I've done another small fix, as the launcher now waits until the app is closed: During an upgrade it's checked whether the launcher is running (not FreeFileSync.exe as before)
Any further comments?
Can we get a few people to test this final version?
Did you want to have a PortableApps.com splash and URL for it, or just release it on your own site and have us link to it?
Sometimes, the impossible can become possible, if you're awesome!
> just release it on your own site and have us link to it?
That would be very easy for me. Is it possible to have some simple redirection page here, that links to the newest version of the *.paf.exe on my sourceforge site?
We do that with Task Coach already since they expressed interest in bringing it in-house.
Once it's tested and verified, we'd just redirect to your SF download from a page in the app directory. You ping us when there is a new release and we verify the new download and then switch it.
Oh, you can still get a splash if you're doing it on your own site. Either a PortableApps.com one. Or you can do a custom one and we can give you a PortableApps.com logo for the corner of it if you'd like.
Sometimes, the impossible can become possible, if you're awesome!
> we'd just redirect to your SF download from a page in the app directory
Sounds good!
> Oh, you can still get a splash if you're doing it on your own site.
I don't have an own site (yet), but it is currently worked on. So, yes, as soon as there is a page in the app directory to link to, it would be nice to have a splash logo.
Just some update: I've released v3.2 with a PortableApps version offically mentioned in changelog.
Best regards, ZenJu
Hi and thanks for your great work. this particular version doesn't appear to be able to run the batch files created without opening the main GUI first. These batch files work fine with the zipped version (which I am also using as a portable). was just wondering why the difference........... thank you again.
For error reports please post on the sourceforge homepage of the tool!
As for your problem I suspect it has to do with conversion of old configuration files to the new format. This happends every couple of releases and is quite normal.
The app looks, nice, but the post should be formatted to the forum guidelines, as seen here. https://portableapps.com/node/11965
Simplifying daily life through technology
No. the error occurs even with newly created Batch files using the latest portable version. and as it seems specific to the .paf file, I thought I'd post it here...
Okay, so the problem is you try to start the batch job by using "FreeFileSyncPortable.exe" which simply redirects to "FreeFileSync.exe" but doesn't pass parameters. I've patched FreeFileSync_3.2.paf.exe and uploaded it again. Should be working now.
For the rapid response (as ever). Will try it tonight.........
Any news on whether this great piece of work would be included in PortableApps???
Just wanted to point out the Development Test Layout Guidelines. If you edit your OP to match it makes it easier for testers/users to assess the progress of the app and decide whether to try it out.
PortableApps.com Advocate
Hey Zenju
Below is a regshot from which I can see shows the dev test is portable. Anyone confirm? Done using XP SP3 with admin rights.
Looking forward to trying 3.3
PortableApps.com Advocate
Not sure whether there's any interest in this anymore but does anyone mind if I upload a dev test of 3.13 (latest PAF, PAL etc.)? (great app btw).
I think the app base would benefit from it. I used it for some time before I switched to Synkron, but that was just my preference. I always found FFS very easy to use.
I seem to remember 'they' released one PortableApps version some time ago, but never bothered to to update it after the initial release. Obviously the developers want to stick with their single installation process and see no reason to add another work stream to their own development work.
Mervyn