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

[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.

[critternyc]

FreeFileSync 7.9 is still affected by this bug. The location of this bug report is now directly linked from the app pages for FreeFileSync on PortableApps.com and PortableFreeware.com.

[Wylie]

A couple of possible workarounds:

Symenu - freeware that is a great portable menu launcher and a Start Menu replacer to organize your applications quickly and easily.
Web address is http://www.ugmfree.it/

Here is what the author of Symenu gave me as possible fixes and they worked for me.

First method:

-Create a batch file and name it: SyMenuStartFreeFileSync.bat
-Place the following code inside the batch file: start "" "FreeFileSync.exe"
-Save the batch file to the FreeFileSync root folder
-Launch the new batch file instead of the normal FreeFileSync.exe file

Second method: If using Symenu app launcher

- Go to SyMenu configuration form
- Add a new Windows command element
- Give it a clear name such as FreeFileSync CMD
- In the command box put the command
start "" plus the full path or your FFS executable replacing the drive
unit letter with the SyMenu universal unit identifier (d: becomes #:)
In my PC the command box contains this string
start "" #:SyMenuProgramFilesSPSSuiteSyMenuSuiteFreeFileSync_spsFreeFileSync.exe

Here is an example batch file to download:

SyMenuStartFreeFileSync.zip

[Wylie]

A couple of possible workarounds:

Symenu - freeware that is a great portable menu launcher and a Start Menu replacer to organize your applications quickly and easily.
Web address is http://www.ugmfree.it/

Here is what the author of Symenu gave me as possible fixes and they worked for me.

First method:

-Create a batch file and name it: SyMenuStartFreeFileSync.bat
-Place the following code inside the batch file: start "" "FreeFileSync.exe"
-Save the batch file to the FreeFileSync root folder
-Launch the new batch file instead of the normal FreeFileSync.exe file

Second method: If using Symenu app launcher

- Go to SyMenu configuration form
- Add a new Windows command element
- Give it a clear name such as FreeFileSync CMD
- In the command box put the command
start "" plus the full path or your FFS executable replacing the drive
unit letter with the SyMenu universal unit identifier (d: becomes #:)
In my PC the command box contains this string
start "" #:SyMenuProgramFilesSPSSuiteSyMenuSuiteFreeFileSync_spsFreeFileSync.exe

Here is an example batch file to download:

SyMenuStartFreeFileSync.zip

Here are a couple of corrections to this post:
The line
start "" #:SyMenuProgramFilesSPSSuiteSyMenuSuiteFreeFileSync_spsFreeFileSync.exe
should be
start "" #:\SyMenu\ProgramFiles\SPSSuite\SyMenuSuite\FreeFileSync_sps\FreeFileSync.exe

A link to the batch file...
Here is an example batch file to download:
http://www.ugmfree.it/public/SyMenuWorkaround/SyMenuStartFreeFileSync.zip

[critternyc]

Wylie: We tried that method at PortableApps.com soon after the bug presented 2 years ago. The standard ways to break out of process are either `start "" "FreeFileSync.exe"` or `cmd /c start "" "FreeFileSync.exe"`. We've found this technique to be only partially effective in neutralizing the bug. On some affected machines, it will work every time. On some it will work about 1/2 the time. And there doesn't seem to be a specific trigger on it either way other than whether the parent or grandparent process is still running as demonstrated with the example code I gave the publisher about a year ago in the thread. So, it's not a complete solution, even just for one proprietary menu.

[critternyc]

In additional testing, it seems that it is indeed the FreeFileSync.exe and FreeFileSync_x86/x64.exe processes that are stepping on each other with locking the options file. This continues to happen when launched from a parent process that remains running (portable menu, portable file manager, 3rd party scheduling utility). This may be related to changes in the way file_handling.cpp lock checks are made between 6.2 and 6.3. It also may be related to the update checker which is buggy when run portably: viewtopic.php?f=2&t=2308

If anyone needs FFS 6.2 and 6.3 to compare, they're available from PortableApps.com here: https://sourceforge.net/projects/portableapps/files/Source/FreeFileSync/