Great, it seems the USB stick is not the cause! > FFS is launched from my C: drive to synchronise a folder in my desktop PCĪnd a network share, the lag is there also So an interesting next test would be toĮxclude the USB stick from the testcase and sync C:\ C:\ and see if it A slow USB stick doesn'tĮxplain why writing to C:\ would lag. Lock file writes on C:\ and L:\ have a 10 second lag. Perhaps your USB stickĪnyway I may be a bit too fast with considering the USB stick responsible.Ĭarefully reanalyzing your first logs, it becomes evident that *both* first Originally I proposed to set "folder permissions" (not the folder attributes),īut your FAT obviously doesn't have NTFS permissions. > I will try and find a way to make the folder truly read-only and come back Tests on different PCs / operating systems / LAN connectivity, etc.) for the lag occurs using the same usb stick irrespective of But it is necessary to identify a single element that is stable inĪll these tests (e.g. At this point almost anything can be theĬulprit. It's a good idea to do various tests changing even seemingly unrelatedĮlements (like LAN cable software). > laptop if it is disconnected from the ethernet cable (?). But over 10 seconds seems excessive for the first write Generally FAT-formatted with caching disabled, which explains part of why theĪccess is slow. The big question is why it is lagging at all. So the assumption that the lag is happening on first write access to L: is > This was the same approach used in Logfile_testFFS_įFS still successfully writes to "L:\testFFS\sync.ffs_lock" (At relative timeĠ6:23:1659170).
#FREEFILESYNC CANNOT SET DIRECTORY LOCK WINDOWS#
Myself (also Windows XP, but no sw installed by the company) I can use to test In the meanwhile I will try and reproduce this on my laptop, to see if the Could FFS beīeing disturbed by any sw both machines have in common? Laptop were configured by the systems department of my company. But on the other hand this makes me think: both the desktop and the I could keep providing you feedback next week (I will be far from my desktop Is disconnected from the ethernet cable (?). This was the same approach used in Logfile_testFFS_īTW, I have to check but I think the lag can be reproduced in my laptop if it FFS won'tĬomplain against failure to create the lock files, but since the lag isĮxpected to be in the write phase (proc mon), comparison should not block this Test directories read-only (set folder permissions accordingly). You can verify this assumption: Use the current v5.0 FFS version and make both So I assembled a testversion which hacks away the check for theĭo you see any change in lag-behavior with this version?Īdvanced test: Although I am pretty sure the lag is related to the lock file Some network drive?), we have writing a lockfile + useless checks on a non-Īt this point I cannot say which of the two accesses (or both) is responsibleįor the lag. Further assuming that access to "L:" is slow (is it "\dev\urandom" is resolved as "L:\dev\urandom" in both cases when creating
#FREEFILESYNC CANNOT SET DIRECTORY LOCK GENERATOR#
The first entry is very odd, a quick research showed that \dev\urandom is poorly chosen as a random number generator seed by a boost library, irrespective that this volume is existent on Linux only and it doesn't make sense to query for it on Windows at all.įrom your video I saw that your working directory is "L:". The process monitor shows two conspicuous entries next to each other: "createfile "L:\dev\urandom" and "Createfile ".
The lag is related to writing the lock file. This may need to be fixed, but it is also a hint to:Ģ. from the video it is obvious that FFS is not responsive while "searching for dir". After analyizing the video and the data there are at least two problems:ġ.
0 kommentar(er)
