PortableApps.com wins big in the 2009 Community Choice Awards and hits 100 million app downloads!
ApplicationsUser loginFollow & Connect With Us   
What is a portable app?
Find out on the What is a portable app? page.
Sponsored Links |
FreeFileSync v3.1Submitted by ZenJu on October 28, 2009 - 2:06pm
Hi, yesterday a user asked for a package on PortableApps. The concept is new to me, but I created one and hosted it on my SourceForge Site: http://sourceforge.net/projects/freefilesync/files/freefilesync/v3.1/Fre... I'm not 100% sure about the next steps: Is there some review-process which Apps are shown on AportableApps.com? Best regards, ZenJu ( categories: )
|
That's fantastic news.
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
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'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
> We'll have some of our members review it and it'll make it into the directory
Great!
Alright, is there anything
Alright, is there anything left for me to do?
Found old .ffs_gui
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
Registry Key?
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
That was the VERY early releases...
The portable version (:= .zip) doesn't need registry.
In the portable version
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.
Data?
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
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
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
Ok
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
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.
That's Fine
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
*pfew* I shortly feared I would have to clean-up after Windows! That would have been some WORK!
Well....
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
Browse
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!
Yup
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
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
> "GlobalSettings.xml" still contains absolute paths
I see two places with absolute paths:
"<"FolderHistoryLeft "\>": These are paths entered by the user, so this should be okay
"<"ConfigHistory "/>": 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!
Theoretically config files
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?
Adjust Paths
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
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?
Included
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,
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,
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?
Final Test?
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
> 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?
Sure
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
> 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.