Can one of the Devs update FreeFileSync 6.2 Portable to 6.4? Usually its done fairly quickly but this one may have slipped through the cracks.
Thanks.
New: Kanri (Oct 9, '24), Platform 29.5.3 (Jun 27, '24)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
We already know that it is outdated (see this thread), but there is a bug that was introduced in 6.3 and is still in 6.4 that prevents us from making it portable.
FFS comes with a perfectly good working portable version.
I have said this before but the PA model is worse not better for this app
Wm
The bug in question is not restricted to PortableApps. It is a bug in the base app that seems to cause issue when it is called by any other executable.
You don't need to spread negativity about it if you don't like it. If you have issue with the PortableApps version, then don't use it.
The PA.c version automatically adjusts paths for you, so you don't have to manually figure out what the relative path is, making it easier for the user. It also installs automatically, updates automatically and switches languages automatically in conjunction with the PA.c Platform. Plus the data is confined to a single directory, making it a snap to backup your settings quickly for multiple apps using the PA.c Platform without needing to backup all your apps, too, making users more likely to do backups.
The base FreeFileSync 6.3 and 6.4 zip versions have a rather serious bug that prevents them from running properly when called by another EXE. It particularly affects batch commands when called by macro utilities, too. FFS will work from a command line or shortcut, but that's about it, so forget about incorporating it into your portable workflow. The bug has been reported to the FFS developers but has not been fixed yet.
Sometimes, the impossible can become possible, if you're awesome!
Thank you for the update.
where should GlobalSettings.xml be? FFS knows where it expects it to be, after all. I think the bug is at the PA end.
But I get moaned at if I say that.
Let me give an example.
If I use FreeCommander XE (the current version from PA) I can't start FFS 6.4
If I use FreeCommander 2009.02b (the version before the current version from PA which I run *outside* PA) I can start FFS 6.4
John TH, I'd like you to take particular note of that because it is a PA app, an exe to be specific, that can and can't work with FFS 6.4
I have looked at your report to FFS
The clue to me is that FreeComander XE doesn't work very well here. But I got moaned at for mentioning that.
How about I try Q-Dir from inside PA, no, that can't run FFS 6.4 either.
How about I run Q-Dir from outside PA, no, that doesn't work.
I'm now going to unistall Q-Dir.
What other test would you like me to run?
that is a question for you winterblood or anyone else that has a valid test to run.
I honestly believe the fault is in PA rather than FFS this time. PA is putting the files in the wrong place at the wrong time. What is wrong with the native portable versions idea of where files should be?
Wm
You're incorrect and apparently did not read the bug report. As I stated in the bug report, I took the standard FFS (NOT FFS Portable, just the FFS portable generated by the publisher) and placed an EXE I created in the same directory. That EXE had a single line of code in it: ExecWait '$EXEDIR\FreeFileSync.exe' All that does is run FreeFileSync.exe in the same directory. That fails with the same error. And, as the other poster in the bug reported, it also fails when he attempts to run it from his macro engine. FFS portable as generated by the publisher's installer (again, not FFS Portable by PA.c) will also fail when you attempt to run it from the PA.c Platform or another menu. FFS fails whenever you run it from another EXE. The bug is absolutely, positively, in the base app itself, as I and others have already proven.
You probably got moaned at for attempting to link some other random issue with this one. If you are having any issues with FreeCommander XE Portable, please post them in another bug report.
Sometimes, the impossible can become possible, if you're awesome!
I just noticed that the installation of the current version of FFS also installs something called "Conduit Search" with no way of opting out. A Google search of "Conduit Search" suggests that this is not something that most folks would want installed.
Assuming that the current problems with 6.3 and 6.4 are eventually solved, I hope that the above mentioned situation is examined.
PortableApps.com Format packages are immune to such add-ons as they are not permitted. If a 3rd party attempts to distribute a PAF app with such an add-on, they are doing so illegally.
Standard installers and zip files have no such restrictions. Several apps we distribute in PAF form have 'tricky' add-ons in their local non-PAF packages. We have no control over that.
Sometimes, the impossible can become possible, if you're awesome!
Trust me, I've spent hours fighting to remove Conduit Search, and related ultra-malware like OpenCandy. It installs to your browser settings, installs deeper into your browsers so that if you remove it as default search or default home page, or default new tab, it reinstalls itself. And then it installs in your Windows registry. It installs to your "Programs and Features", but uninstalling that part has no effect. It does all this well enough that your virus removal software can't remove it. Malwarebytes cannot remove either it from the infected system. However, if you run Malwarebytes from a Linux installation to scan your Windows partition, it can find more of it to remove. Junkware Removal Tool helps if you run it after infection but before you reboot.
If the creator of FFS is so, (IMO evil) as to consider using Conduit/OpenCandy, then I would never install any version they release. In fact, many Conduit/OpenCandy software "partners" release regular updates without meaningful fixes or features just so they can exploit Conduit's newest added features of defeating more anti-malware tools.
If you can't work out an optional install use the firearm you just bought against your own head
Wm
No matter how sarcastically intended, please stop this style of post.
Sometimes, the impossible can become possible, if you're awesome!
"The base FreeFileSync 6.3 and 6.4 zip versions have a rather serious bug that prevents them from running properly when called by another EXE."
- from https://portableapps.com/node/41219#comment-214946
I just installed v6.10 in portable mode (from the installer). FreeFileSync.exe seems to run fine if called/run using PStart. I don't know if this helps the dev in any way. And, sorry to bump a old thread.
It seems to work with some EXEs but not others with no rhyme or reason. Multiple users have complained that the base app locally installed works sometimes from their automated scheduler and other times fails with the error shown. For some reason, one of FFS's EXEs thinks the other has the settings file locked and fails. Both the base shortcut EXE and the x86/x64 actual EXEs check for locks and appear to lock each other out. FFS fails with its base 'portable' install from its installer into the PA.c Platform. It also fails when run from a simple EXE I built that only launches it. Sadly, the author doesn't seem very interested in exploring the issue.
Sometimes, the impossible can become possible, if you're awesome!
I saw the change log and wrote a small nsis script :
Exec '$EXEDIR\FreeFileSync.exe'
it worked OK.
It fails about 1/2 the time when being launched from PAL with the exact same error. No rhyme or reason for why it fails once then immediately works then fails again on relaunch. Definitely still broken.
Sometimes, the impossible can become possible, if you're awesome!