BUG: Starting FreeFileSync.exe from another process yields Error Code 32

[bennieboj]

Well Zenju responded once on this thread so he tried, but most likely does not care enough about this. yet he responded to another topic about 5 days ago. Maybe the flag by ESET could be a false positive?

[bennieboj]

I've been looking in to this atm.
I cannot build FFS, I never tried to build it only have msvs2012 installed at the moment and I'm having problems with a file "wx+\pch.cpp" not being found. Anyhow, I digged through some of the code from 6.2 and 6.3. I diffed all the files using WinMerge but I couldn't make much out of the changed things (just to much changes, not familiar with the code etc).


Then since the error mentioned not something about not being able to open a file *GlobalSettings.xml*, I started grepping on the 6.3 code. I found it wasn't used as a literal, but most as the xmlAccess::getGlobalConfigFile() function in lib/process_xml.cpp.
Of course it is possible that another variable holds the same filename inside some of the settings files, but this is the only direct reference grep could find.
So we know: look for getGlobalConfigFile().

Then I grepped on *"Cannot open file"*, lots of references mostly in unimportant language files, some in application.cpp unrelated to our xml file (no mention of getGlobalConfigFile()) one important one in file zen/file_io.cpp in the FileInput function.

Next question, do we get from the application.cpp file to the file_io.cpp file? TL;DR: yes.
Long version: The *runBatchMode* function in application.cpp calls *readConfig(getGlobalConfigFile(), globalCfg, warningMsg)* which is a call to void *xmlAccess::readConfig(const Zstring& filename, xmlAccess::XmlGlobalSettings& cfg, std::wstring& warningMsg)* in process_xml.cpp which calls *void readConfig(const Zstring& filename, XmlType type, ConfigType& cfg, int currentXmlFormatVer, std::wstring& warningMsg)* in the same file with the correct parameters. Sorry for the long function definition copy pastes, but the file contains a lot of fuctions named "readConfig", so better safe than sorry.
Now this template function calls loadXmlDocument(const Zstring& filename) from zen/xml_io.cpp., which on his turn uses the FileInput function mentioned earlier.

So I *think* I found where the error occurs, just not why, or what made build starting from 6.3 break when called from another process. The only thing changed from 6.2 to 6.3 related to these files I just mentioned are in *file.io.cpp*. There are other edits in the code but they are not executed until after the crash I believe. The main thing that changed in file_io.cpp is the addition of Source-Code Annotation Language (_In_ and _In_opt_) at the CreateFile call which aren't interpreted by the compiler anyhow IIRC.

This was my 2 cents, hope this gets fixed soon. I'm willing to test debug versions and offer dumps of all kinds (like I did last time) if I have time :D

[b8375629]

Well Zenju responded once on this thread so he tried, but most likely does not care enough about this. yet he responded to another topic about 5 days ago. Maybe the flag by ESET could be a false positive?

Yeah, that was months ago. If he cared, he'd fix it.

I tried testing this in a sandbox and it still wouldn't let me load, giving me a 'runtime error message'

Nope, I'm afraid this is done. Best to look for alternatives out there. Do you have any you'd recommend?

[Zenju]

I've been looking in to this atm.
I cannot build FFS, I never tried to build it only have msvs2012 installed at the moment and I'm having problems with a file "wx+\pch.cpp" not being found. Anyhow, I digged through some of the code from 6.2 and 6.3. I diffed all the files using WinMerge but I couldn't make much out of the changed things (just to much changes, not familiar with the code etc).


Then since the error mentioned not something about not being able to open a file *GlobalSettings.xml*, I started grepping on the 6.3 code. I found it wasn't used as a literal, but most as the xmlAccess::getGlobalConfigFile() function in lib/process_xml.cpp.
Of course it is possible that another variable holds the same filename inside some of the settings files, but this is the only direct reference grep could find.
So we know: look for getGlobalConfigFile().

Then I grepped on *"Cannot open file"*, lots of references mostly in unimportant language files, some in application.cpp unrelated to our xml file (no mention of getGlobalConfigFile()) one important one in file zen/file_io.cpp in the FileInput function.

Next question, do we get from the application.cpp file to the file_io.cpp file? TL;DR: yes.
Long version: The *runBatchMode* function in application.cpp calls *readConfig(getGlobalConfigFile(), globalCfg, warningMsg)* which is a call to void *xmlAccess::readConfig(const Zstring& filename, xmlAccess::XmlGlobalSettings& cfg, std::wstring& warningMsg)* in process_xml.cpp which calls *void readConfig(const Zstring& filename, XmlType type, ConfigType& cfg, int currentXmlFormatVer, std::wstring& warningMsg)* in the same file with the correct parameters. Sorry for the long function definition copy pastes, but the file contains a lot of fuctions named "readConfig", so better safe than sorry.
Now this template function calls loadXmlDocument(const Zstring& filename) from zen/xml_io.cpp., which on his turn uses the FileInput function mentioned earlier.

So I *think* I found where the error occurs, just not why, or what made build starting from 6.3 break when called from another process. The only thing changed from 6.2 to 6.3 related to these files I just mentioned are in *file.io.cpp*. There are other edits in the code but they are not executed until after the crash I believe. The main thing that changed in file_io.cpp is the addition of Source-Code Annotation Language (_In_ and _In_opt_) at the CreateFile call which aren't interpreted by the compiler anyhow IIRC.

This was my 2 cents, hope this gets fixed soon. I'm willing to test debug versions and offer dumps of all kinds (like I did last time) if I have time :D

so far it seems this problem is only occurring in the context of PortableApps and not when starting normally from Windows Explorer. Most likely it is caused by some conflict with the PA configuration handling on startup that makes applications portable.

[critternyc]

so far it seems this problem is only occurring in the context of PortableApps and not when starting normally from Windows Explorer. Most likely it is caused by some conflict with the PA configuration handling on startup that makes applications portable.

Hi Zenju. I've been looking at this bug for a while. It's nothing to do with our packaging. Even when running your standard portable version installed from your installer directly with none of our added bits from the PortableApps.com Menu... which does nothing but run an EXE directly... it produces the mentioned error. The code being executed when a user runs FFS from our menu is only this (replacing the actual strings for the internal variables for readability:

ShellExecute(0,'open', PChar('P:\PortableApps\FFS\FreeFileSync.exe'+#0),Nil, PChar('P:\PortableApps\FFS'+#0), SW_SHOWNORMAL);

The same error occurs for me when run from a locally-installed scheduler utility as well as when run from 3rd party file explorers. Even if you run it from an EXE that just runs FreeFileSync.exe (more on that in a minute).

It's also worth noting that the FreeFileSyncPortable.exe launcher used in our FreeFileSync Portable package was last altered/compiled in October of 2013 and worked perfectly fine up until FreeFileSync 6.3 in March of 2014 when FFS stopped working with 3rd party schedulers, file explorers, etc as well.

I explored the diffs of 6.2 to 6.3, when the issues started, and could not see anything that should be causing the issue.

I have produced an EXE with just a single line of code in NSIS to run FreeFileSync.exe and then wait for it to stop running and it produces the bug as well. You can download my simplified bug reproducer here:
http://portableapps.com/downloads/temp/FreeFileSyncBug.zip

Just place FreeFileSyncBug.exe in the same directory as FreeFileSync.exe and run it.

The bug seems to occur when the Windows process that runs FreeFileSync.exe remains running. If the process exits immediately after running FreeFileSync.exe, the bug does not seem to occur occur. To that end, I also included FreeFileSyncNoBug.exe which will Exec FreeFileSync.exe and then immediately exit. This does not produce the bug on my system. If, however, I add Sleep 10000 after the Exec to keep the exe running for 10 seconds after launching FreeFileSync.exe, the bug occurs.

I've included both EXEs as well as the source code within the above linked zip file. You can compile them yourself using NSIS Unicode Portable (or local, for that matter).

If you need any additional assistance or details, please just let me know.

[critternyc]

so far it seems this problem is only occurring in the context of PortableApps and not when starting normally from Windows Explorer. Most likely it is caused by some conflict with the PA configuration handling on startup that makes applications portable.

[invenio78]

I can confirm that this is not a "portableapps" issue. I installed freefilesync just today using it's installer and defined as "portable mode." It would not start with double clicking on the main exe file with windows explorer.

This has been broken for a year now. Whoever is writing the code, PLEASE LOOK INTO THIS. I am stuck using version 6.3 of the software since this bug was introduced.

I am not a computer programmer so I don't know about the technical workings but I can post a screenshot of the error if desired.

[pudah]

I use batch files to run several utilities, including FreeFileSync, from a USB flash drive.

The batch files sit in the root folder of the USB drive. The utilities are in \UTILS\ProgramName folders. Contents of batch file is as follows:

@echo off
cd /d %~dp0
cd \UTILS\FreeFileSync
START /b FreeFileSync.exe

Double clicking on this batch file used to work just fine, but no longer does in recent versions. I get the dreaded Error Code 32 error message. This happens in Windows XP and Windows 7. When I use Windows Explorer or the Free Commander file manager. Or even try to run the batch file from Start | Run.

However, if I open a command window in the root of the flash drive and execute the batch file that way, it works fine.

It would be great if this bug could be fixed. I can still run the program. But it's a real pain to have to launch a DOS box to do so.

[intexx]

Zenju... if you'd charge money for FFS, as I requested here, you'd be able to justify the time to find and fix problems like this.

With the proper attention, I imagine it could be fixed in a week. Not a year.

Thanks,
Jeff Bowman
Fairbanks, Alaska

[intexx]

It'd be nice to hear from you on this, Zenju.

As it stands, it looks like I'm going to have to switch to RoboCopy for my automated sync jobs.

FFS still remains the best for one-off, ad-hoc projects, but for repetitive CLI-based actions there just seem to be too many problems. Can't run FFS from another process? Hard-to-parse log files? No file-level detail when folders are deleted under a Mirror action?

All of these--and possibly more, yet undiscovered?--contribute to a significant impediment to FFS automation, I'm afraid to say.

And for the life of me I can't figure out why you're not participating in this particular discussion. Not even to help some of the other requesting folks pinpoint the relevant section of code. For over a year. Goodness.

Thanks,
Jeff Bowman
Fairbanks, Alaska

[virtualvirgo]

I, too, wish to know if there is a possible solution in the (hopefully) near future. This software was part of an academic network backup project, and the fact that it was properly portable when run from a launcher was the icing on the cake. That was last applicable with version 6.2. Can you please address this, Zenju? Is this project still active? If so, what are your plans to remedy the issue?

VV

[invenio78]

I agree with the above posters, I don't see why such a major bug has not been addressed after so many version updates. I am still using a version from over a year ago! I'm really close to going with another application. I just wish Zenju would at least comment on the status of this issue. Is it going to be fixed?,.. I can even understand if it's too much work or something. But to have all these issues with launching the program is crazy.

Zenju, if you read this. You've got an awesome program. Please take a look at this issue!

[bennieboj]

I second this once more!
Still willing to submit bug reports and the like btw.

[decay2112]

Hi Zenju. I've been looking at this bug for a while. It's nothing to do with our packaging. Even when running your standard portable version installed from your installer directly with none of our added bits from the PortableApps.com Menu... which does nothing but run an EXE directly... it produces the mentioned error. The code being executed when a user runs FFS from our menu is only this (replacing the actual strings for the internal variables for readability:

ShellExecute(0,'open', PChar('P:\PortableApps\FFS\FreeFileSync.exe'+#0),Nil, PChar('P:\PortableApps\FFS'+#0), SW_SHOWNORMAL);

The same error occurs for me when run from a locally-installed scheduler utility as well as when run from 3rd party file explorers. Even if you run it from an EXE that just runs FreeFileSync.exe (more on that in a minute).

It's also worth noting that the FreeFileSyncPortable.exe launcher used in our FreeFileSync Portable package was last altered/compiled in October of 2013 and worked perfectly fine up until FreeFileSync 6.3 in March of 2014 when FFS stopped working with 3rd party schedulers, file explorers, etc as well.

I explored the diffs of 6.2 to 6.3, when the issues started, and could not see anything that should be causing the issue.

I have produced an EXE with just a single line of code in NSIS to run FreeFileSync.exe and then wait for it to stop running and it produces the bug as well. You can download my simplified bug reproducer here:
http://portableapps.com/downloads/temp/FreeFileSyncBug.zip

Just place FreeFileSyncBug.exe in the same directory as FreeFileSync.exe and run it.

The bug seems to occur when the Windows process that runs FreeFileSync.exe remains running. If the process exits immediately after running FreeFileSync.exe, the bug does not seem to occur occur. To that end, I also included FreeFileSyncNoBug.exe which will Exec FreeFileSync.exe and then immediately exit. This does not produce the bug on my system. If, however, I add Sleep 10000 after the Exec to keep the exe running for 10 seconds after launching FreeFileSync.exe, the bug occurs.

I've included both EXEs as well as the source code within the above linked zip file. You can compile them yourself using NSIS Unicode Portable (or local, for that matter).

If you need any additional assistance or details, please just let me know.

Regarding your statement: "The bug seems to occur when the Windows process that runs FreeFileSync.exe remains running. If the process exits immediately after running FreeFileSync.exe, the bug does not seem to occur occur."

I presume you've tried creating an exe that launches FFS then exits immediately and tried launching THAT from within the portable apps framework? Just thought this would be worth mentioning on the off chance that it was just the calling process that needed to exit and not the entire process chain.

Thanks.

[critternyc]

Regarding your statement: "The bug seems to occur when the Windows process that runs FreeFileSync.exe remains running. If the process exits immediately after running FreeFileSync.exe, the bug does not seem to occur occur."

I presume you've tried creating an exe that launches FFS then exits immediately and tried launching THAT from within the portable apps framework? Just thought this would be worth mentioning on the off chance that it was just the calling process that needed to exit and not the entire process chain.

Thanks.

I tried exactly that last year. It also winds up with the error.

[critternyc]

The bug is still present in FreeFileSync 7.0.

[mikeclueby4]

As a random C programmer: it sounds like FreeFileSync.exe is keeping the file handle open while launching the bin/FreeFileSync_Win32.exe / bin/FreeFileSync_x64.exe. If the launcher manages to quit before the main exe accesses the file, it works, otherwise not.

It sounds a bit wonky that how the launcher is started matters though.. is the file handle getting associated with the process group rather than the process? Either way, closing it in the launcher before firing up the main exe should fix it.

As a test, try directly executing the bin\FreeFileSync_Win32.exe file from your custom exe / menu and see if that works better?

[critternyc]

As a random C programmer: it sounds like FreeFileSync.exe is keeping the file handle open while launching the bin/FreeFileSync_Win32.exe / bin/FreeFileSync_x64.exe. If the launcher manages to quit before the main exe accesses the file, it works, otherwise not.

It sounds a bit wonky that how the launcher is started matters though.. is the file handle getting associated with the process group rather than the process? Either way, closing it in the launcher before firing up the main exe should fix it.

As a test, try directly executing the bin\FreeFileSync_Win32.exe file from your custom exe / menu and see if that works better?

I had tried that when the issue first started without success since the PA.c Launcher can handle automatically selecting the proper one.

[invenio78]

I can't believe this issue has not been addressed in over a year.

Can the developer way in on what he thinks is going on?

[oliver_sahr]

Hello,

this problem occurs when I start FreeFileSync 7 Portable from the file manager FreeCommander.
Unfortunately this can not 100% be reproduced, sometimes it works.

Please fix this nasty bug because I have to open the Windows Explorer for starting FreeFileSync Portable.
Thank you!

Greetings

OLLI

[oliver_sahr]

Hello,

version 7.1 still has this nasty bug.

I downloaded 7.1 it and installed it as portable version and I was able to start it from "FreeCommander XE" three times without any problems (start FreeFileSync, close it, wait some seconds and start it again).

But now FreeFileSync shows this error message when I start it.
Sometimes it can be started, sometimes the error is shown.
I made sure that no "FreeFileSync" process is running before I started it.

Zenju, can I somehow help you finding this bug?
Does FreeFileSync create any log files (is there a switch to turn logging on)?

Greetings

OLLI

[invenio78]

7.2 still has this bug. Make the program completely unusable. Can the developer please at least acknowledge that this is a program breaking bug? Is there ever going to a fix?

[echtatze]

Do the programs you are starting ffs from allow to provide a working folder?
Maybe thats a difference?

[critternyc]

Do the programs you are starting ffs from allow to provide a working folder?
Maybe thats a difference?

Setting a working folder has no affect.

[malexm]

The current version 7.4 has the same problems...

[critternyc]

Attempting to run FreeFileSync.exe from another process on Windows yields the following error:

---------------------------
FreeFileSync - An exception occurred
---------------------------
Cannot open file "GlobalSettings.xml".

Error Code 32: The process cannot access the file because it is being used by another process. (CreateFile)

This does not occur from a batch file but does occur when run from another EXE. I found the issue while packaging the PortableApps.com Format package of the app and thought it may be due to an interaction with our launcher, but created a simplified NSIS-based EXE that only does one thing (ExecWait '$EXEDIR\FreeFileSync.exe') and it yields the above error as well. We may be able to code around it in our package, but I'd wager this will cause issue when run from some other scheduling software and alternate Windows Start menus.

This bug still persists in version 7.6. I included a full set of tests of a minimum viable setup to reproduce the bug months ago as well as details on the last version that permitted launching from a 3rd party file manager, menu, or any other process. As it has been 20 months, it seems unlikely this bug will be fixed.

[critternyc]

This bug still persists in 7.6. I have complete details to reproduce in the report from 9 months ago: viewtopic.php?t=1716&p=6995#p6995

This bug is now 20 months old and still doesn't allow FreeFileSync to be launched from 3rd party file managers, menus, and other processes.

[critternyc]

This bug still persists in FreeFileSync 7.8. The bug is now 22 months old. Complete details on how to reproduce it along with source code and a stub launcher to do so were provided 11 months ago.

If you'd like to use FreeFileSync with a start menu of your choice, a file manager of your choice, or any other software, you can obtain version 6.2, the last properly working version, from here: http://portableapps.com/apps/utilities/freefilesync-portable

[luismbs]

I'm sorry I made a new thread about this, I didn't assume this would be a persistent issue since it never happened to me before, and I've been updating FFS promptly every month.

I'm baffled as to why this particular issue hasn't been tracked down and addressed yet. I mirror the same experience others have posted here. That said, I have not met this error today (I run and closed FFS over 10 times, no issues), and as I mentioned in the thread I created, this only happened yesterday in one of my PCs after having used FFS several times in the last few days since the 7.8 update, and I haven't had any issues with FFS on the other PCs with very similar software setups. It's funny how it seemingly manifested at random only yesterday, intermittently too.

Other than restarting my system (or rather, turned it off yesterday to turn it on today), no changes were made that could possibly interfere with the software's behavior, after or before I'd say. I might as well add that this didn't ruin my day or anything, and I will continue to use this amazing utility as long as this bug doesn't become crippling for daily use.

[sashaoli]

Hello!
I beg pardon for my English. I use Google Translator ...

This problem, error code 32, came to me too.
I take LiberKey ...
And, wrote FreeFileSync Portable small launcher for windows.
The utility needs wider testing.
Distributed freely without any conditions.
Download FreeFileSyncLaunch
Hash List
MD5 ab5d8cc39b53f6a45f401c0f0cfaabc1
SHA1 0b1e5d8d19bf0588d2374a293046062cbb3a8ef0
SHA256 25406109179ada87d5c74680399edba91ab0918f12a04972929e15ed1b7419d7

I would appreciate your feedback.