![]() You can compile them yourself using NSIS Unicode Portable (or local, for that matter). I've included both EXEs as well as the source code within the above linked zip file. If, however, I add Sleep 10000 after the Exec to keep the exe running for 10 seconds after launching FreeFileSync.exe, the bug occurs. ![]() This does not produce the bug on my system. To that end, I also included FreeFileSyncNoBug.exe which will Exec FreeFileSync.exe and then immediately exit. If the process exits immediately after running FreeFileSync.exe, the bug does not seem to occur occur. ![]() The bug seems to occur when the Windows process that runs FreeFileSync.exe remains running. Just place FreeFileSyncBug.exe in the same directory as FreeFileSync.exe and run it. You can download my simplified bug reproducer here: 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. 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. 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. Even if you run it from an EXE that just runs FreeFileSync.exe (more on that in a minute). The same error occurs for me when run from a locally-installed scheduler utility as well as when run from 3rd party file explorers. ShellExecute(0,'open', PChar('P:\PortableApps\FFS\FreeFileSync.exe'+#0),Nil, PChar('P:\PortableApps\FFS'+#0), SW_SHOWNORMAL) 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: which does nothing but run an EXE directly. Even when running your standard portable version installed from your installer directly with none of our added bits from the Menu. I've been looking at this bug for a while. And this would have to duplicate with every branch of DFS that works in this way.Hi Zenju. with your method instead of being able to specify simply one parent path, I would need to set up 24. For instance, under "\video\education" there may be two dozen DFS targets that I want to copy. Your workaround of "sync against a subfolder" would work, but it would also create a tedious amount of work. After all, if it won't work in any other way, then providing a way for it to work is better than not at all - even if it means you need to ensure your FFS instance is properly configured with the custom location. However, in short, while I understand your statement above that the file needs to be found by any FFS instance, that wouldn't preclude having a custom location option. If not, please let me know and I will try to be more descriptive. I am going on the assumption that you understand/have some experience with DFS and understand these issues. In this case, nothing can be created in "education" because education is a DFS folder with no target (whose purpose is simply organizational). īecause of the nature of DFS, some folders may not map to actual targets. I get the following on my copies between my DFS data and backup locations:ġ0:47:58 AM WarningĜannot set directory locks for the following folders:Ĭannot write file "\\mediabase\data\media\video\education\sync.ffs_lock".Įrror Code 5: Access is denied. I'm reviving this long dormant thread to bring up another case use of this issue which I can see no great workaround for: Needs to be found by any FFS instance no matter how it is configured. Wouldn't make much sense to store the lock file in any other place: the file folder's root imposes folder's rights that are not compliant to my use.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |