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

Posts: 27 · critternyc 7 Mar 2014, 23:52

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.

POSSIBLE WORKAROUND: You may be able to work around this issue by creating a batch file and launching FreeFileSync from that. Create a file called freefilesync.bat in your ffs folder and have the contents be:

START /b FreeFileSync.exe

Note that this may or may not work when launched from another process like a third party menu, third party file manager or third party scheduling utility. Credit to volpoca on the PortableApps.com forum for coming up with this workaround in January 2015.

BUG REPRODUCTION: I created a set of EXEs to demonstrate the bug in February 2015 and posted them in this thread: viewtopic.php?t=1716&start=25#p6995

Posts: 27 · critternyc 1 Apr 2014, 23:29

This bug is still present in the 6.4 release.

Posts: 6 · dragonetti 7 Apr 2014, 23:23

I just started with FreeFileSync, and I think I have encountered the same "bug".
I use the program QuickMacros to make my own mini-applications/macros, when I run the command-line batch command described in the help-file through QuickMacros I get the same error described by John T. When I run the same command through windows CMD (command-line) then everything works.

Is there anything I can do to work around this? Or will this be resolved in the next version?

Posts: 6 · ralatsf 18 Apr 2014, 10:39

Same for me. Attempting to start FreeFileSync 6.3 or 6.4 (portable install on a USB Flash Drive) via my application launcher ASuite gives:

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

Posts: 7505 · Zenju 24 Apr 2014, 09:55

Does the problem also occur with the 6.5 beta?
[404, Invalid URL: http://freefilesync.sourceforge.net/FreeFileSync_6.5_beta_Windows_Setup.exe]

Posts: 6 · dragonetti 25 Apr 2014, 14:35

@Zenju
When I am in code edit mode in my program 'Quick Macros' and I run a simple command to start freefilesync.exe then it works (6.5 beta).
This was not the case in the 6.4 version, there I got the error:
Cannot open file "GlobalSettings.xml".

But I still get the error when I compile the command from the program 'Quick Macros' to an executable. Maybe my issue is more related to 'Quick Macros', I do not know.

EDIT 1:
And now it seems to work!
I have no idea what caused it not to work and then working again.
To clarify => At this moment I have no errors anymore (no errors when working from my application 'Quick Macros' and when I compile to executable).

EDIT 2:
And now the compiled executable that starts 'freefilesync' doesn't work anymore. (It still does work when I am in code edit mode in my 'Quick Macros' application).
So it's back to the original situation like I stated in the beginning of this post. (Sorry for this second edit).

Posts: 27 · critternyc 25 Apr 2014, 17:42

The error still occurs in 6.5 beta when run within the FFS Portable PA.c Format package or when a standard portable install directly from the 6.5 beta installer is run from the PA.c Platform's menu. Same error as reported above.

Posts: 1 · bovender 26 Apr 2014, 05:55

I have the same problem, running FFS 6.4 from a USB stick with PortableApps on Windows. Reverted to 6.3, works fine.

Posts: 27 · critternyc 1 May 2014, 19:43

This issue persists in FreeFileSync 6.5. Downloading the official Windows installer from here and installing in portable mode. When attempting to run it from the PortableApps.com Menu, we still get Error Code 32. FFS in portable mode still can't be launched from an external EXE (an app launcher, a scheduler, etc).

Posts: 2 · silverray 1 Jun 2014, 16:36

Same for me on FFS 6.6 on wPP and PA
back to 6.3

Posts: 27 · critternyc 2 Jun 2014, 02:12

The issue persists in FFS 6.6. Starting FreeFileSync.exe via another process still produces the above error, so it can only be started via Windows Explorer, a shortcut, command line, or a batch file.

Posts: 85 · blues12 2 Jun 2014, 05:17

Confirmed. Same here. Still not fixed.

Posts: 27 · critternyc 1 Jul 2014, 15:31

This bug is still present in FreeFileSync 6.7. The app simply can not be run from other menus, scheduling apps, etc.

Posts: 2 · oxsmos 1 Jul 2014, 23:23

Should diff between versions 6.2 and 6.3...that are respectively the last good and first bad with this issue

Posts: 27 · critternyc 28 Jul 2014, 18:06

I did a quick skim of the diff between 6.2 and 6.3 and nothing jumped out at me. Granted, I haven't determined where in the code this error is being thrown incorrectly. Perhaps someone with better C++ chops could take a look or the author could point us to where this invalid error is being thrown from.

Posts: 2 · silverray 1 Aug 2014, 15:00

I'm getting the same error in ffs 6.8

Posts: 27 · critternyc 1 Sep 2014, 21:05

This bug is still present in FreeFileSync 6.9. Anyone more versed in C++ than me care to take a stab at examining the DIFF between FFS 6.2 and 6.3 and determine how the bug was introduced?

Posts: 27 · critternyc 20 Oct 2014, 22:25

If it helps at all, the error is occurring within freefilesync.exe. Substituting that file from 6.2 into 6.3 fixes the error. So the error is in the code of this 'shortcut' exe instead of within the main EXEs that it calls within Bin.

Posts: 4 · bono82 21 Oct 2014, 11:57

Same error here. We use the installed version, not portable. Everything worked fine until we upgraded to 6.10. We use a scheduled script which call FreeFileSync with parameter(.ffs_batch). Now we get the following error message(see attached screenshot): "Cannot open file "GlobalSettings.xml".
Error Code 32: The process cannot access the file because it is being used by another process. (ReadFile)". We uninstalled it and installed the last "good" version (6.9), but unfortunately the problem is same. I tried to copy the .exe from version 6.2 as John suggested, but it did not help.

I tried to call FreeFileSync_Win32.exe directly from the script, but it did not help.

Anyone has another idea?

Posts: 27 · critternyc 21 Oct 2014, 22:03

Yes, this affects the app in 'installed' mode as well as portable. So, you can't run it from anything else except Explorer or the Windows Start/Tile Menu.

Posts: 4 · bono82 22 Oct 2014, 05:56

Yes, but it is strange, because sometimes it workes from TaskScheduler, but mostly doesn't. I don't know what is the difference.

Posts: 27 · critternyc 4 Nov 2014, 10:36

FreeFileSync 6.11 fails about 1/2 the time when launched from another EXE. There doesn't appear to be any rhyme or reason to why it fails some times but not others.

Posts: 1 · jwayfarer 2 Jan 2015, 11:26

Bug is still present on FreeFileSync 6.12.

Tested on Windows 7 Professional x64 Spanish, fully updated, using the following apps as launchers:

- PortableApps.com Platform 12.0.5 -> Fail
- CubicExplorer 0.95.1 Portable -> Fail
- Console 2.00.148 Portable -> Fail
- Explorer++ 1.3.5.531 Portable -> Fail
- Process Hacker 2.33 Portable (Run dialog) -> Fail

Strangely, sometimes it does not fail, though I have not been able to find a specific reason for that. Launching FreeFileSync.exe through a .cmd file with only one line "cmd /c FreeFileSync.exe" fails also.

May it be an antivirus issue? It's sooo strange...

Posts: 26 · fractals 13 Jan 2015, 18:06

As FreeFileSync is open source, would it be possible to run it and step through the code with a debugger to find precisely where it is failing?

I really like FreeFileSync Portable. Version 6.2 still seems to work well, but it would be really nice to be able to use a newer version, as 6.2 is about a year old now.

Posts: 2 · b8375629 24 Jan 2015, 18:36

Looks like this is abandonware since it's been almost a year since this issue has been addressed and Zenju has said anything about it.

Not to mention this is being now being flagged as malware since ESET reports a Win32/FusionCore.A infection in it's .exe file.

Could well be looking for an alternative for this.

Posts: 13 · bennieboj 25 Jan 2015, 10:10

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?

Posts: 13 · bennieboj 25 Jan 2015, 12:28

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

Posts: 2 · b8375629 26 Jan 2015, 05:25

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

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?

Posts: 7505 · Zenju 29 Jan 2015, 18:09

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 :Dbennieboj

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.

Posts: 27 · critternyc 11 Feb 2015, 21:26

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

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.

Posts: 27 · critternyc 11 Feb 2015, 21:38

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

Posts: 4 · invenio78 1 Mar 2015, 04:23

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.

Posts: 1 · pudah 4 Apr 2015, 11:14

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.

Posts: 21 · intexx 7 Apr 2015, 07:43

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

Posts: 21 · intexx 17 Apr 2015, 08:34

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

Posts: 1 · virtualvirgo 25 Apr 2015, 03:51

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

Posts: 4 · invenio78 25 Apr 2015, 18:08

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!

Posts: 13 · bennieboj 30 Apr 2015, 08:49

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

Posts: 1 · decay2112 2 May 2015, 14:40

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

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.

Posts: 27 · critternyc 3 May 2015, 01:39

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

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

Posts: 27 · critternyc 12 May 2015, 00:03

The bug is still present in FreeFileSync 7.0.

Posts: 2 · mikeclueby4 23 May 2015, 03:02

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?

Posts: 27 · critternyc 27 May 2015, 19:20

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?mikeclueby4

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

Posts: 4 · invenio78 28 May 2015, 20:34

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?

Posts: 2 · oliver_sahr 3 Jun 2015, 15:10

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

Posts: 2 · oliver_sahr 9 Jun 2015, 06:00

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

Posts: 4 · invenio78 4 Jul 2015, 01:26

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?

Posts: 26 · echtatze 4 Jul 2015, 08:47

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

Posts: 27 · critternyc 30 Jul 2015, 02:22

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

Setting a working folder has no affect.

Posts: 1 · malexm 28 Sep 2015, 12:43

The current version 7.4 has the same problems...