The bug is absolutely, positively, in the base app itself, as I and others have already proven. FFS fails whenever you run it from another EXE.
#Portale app freefilesync portable#
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. And, as the other poster in the bug reported, it also fails when he attempts to run it from his macro engine. 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. 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. You're incorrect and apparently did not read the bug report. What is wrong with the native portable versions idea of where files should be? PA is putting the files in the wrong place at the wrong time. I honestly believe the fault is in PA rather than FFS this time. That is a question for you winterblood or anyone else that has a valid test to run. What other test would you like me to run? How about I run Q-Dir from outside PA, no, that doesn't work.
How about I try Q-Dir from inside PA, no, that can't run FFS 6.4 either. The clue to me is that FreeComander XE doesn't work very well here. 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 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 If I use FreeCommander XE (the current version from PA) I can't start FFS 6.4 Where should GlobalSettings.xml be? FFS knows where it expects it to be, after all.
0 kommentar(er)
