After clicking Stop the dialog shows "Stop requested... 0%" and shows it had processed 0 bytes (I clicked stop rather quickly) and that it is in the middle of "Creating file" on destination app was hung in that state for approximately 10 minutes.
When the app finally became responsive it showed an Error and a list of files that failed to write, even after I clicked STOP. There are dozens of "ENOENT: No such file or directory" errors.
I think what happened was a directory was renamed after compare which resulted in errors. But why should FreeFileSync take 10 minutes to become responsive after clicking STOP ?
FreFileSync on Mac 'hangs' on Stop requested
- Posts: 6
- Joined: 5 Dec 2023
- Posts: 6
- Joined: 5 Dec 2023
I think I have more information... even without the error of a renamed folder, I experienced the same issue when I attempted to stop the same synchronization job.
I think the root cause is the source of synchronization is a OneDrive folder and the files are being 'just in time' downloaded by OneDrive as they are opened by FreeFileSync. And, when I click stop FreeFileSync is blocked waiting on OneDrive.
In this second scenario when I "Stop" it still takes about 10 minutes before FreeFileSync is responsive, and FreeFileSync shows an 'Error' status. There just aren't any errors in the list this time.
I think the root cause is the source of synchronization is a OneDrive folder and the files are being 'just in time' downloaded by OneDrive as they are opened by FreeFileSync. And, when I click stop FreeFileSync is blocked waiting on OneDrive.
In this second scenario when I "Stop" it still takes about 10 minutes before FreeFileSync is responsive, and FreeFileSync shows an 'Error' status. There just aren't any errors in the list this time.
- Posts: 1
- Joined: 5 Dec 2023
On my MAC I'm consistently getting a fatal error trying to install the latest (13.2) update, "failed to copy" error.
- Posts: 6
- Joined: 5 Dec 2023
Sorry so late in posting this, but I eventually figured out what was going on. I was synchronizing with a Cloud storage provider that was just-in-time downloading files for the synchronization (can't recall if it was OneDrive or Google Drive). But it turns out for some reason FreeFileSync blocked the UI thread for a *long* time while files were being downloaded from the cloud storage.
It would be nice if this could be fixed and FreeFileSync was more asynchronous and didn't block when 'streaming' files from the cloud.
It would be nice if this could be fixed and FreeFileSync was more asynchronous and didn't block when 'streaming' files from the cloud.
-
- Posts: 4056
- Joined: 11 Jun 2019
Considering your earlier posts specified OneDrive, that is likely the one in use. This isn't a FFS issue though, it is how the VFS is implemented by the cloud provider, unfortunately. FFS makes a system call to get a file and must wait to receive a response in order to do anything further, including stopping.
- Posts: 6
- Joined: 5 Dec 2023
While it may be true that a synchronous I/O call "must" wait for the result before execution on that thread continues. It appears the I/O operation is happening on the foreground, or UI, thread. This entirely blocks the user from interacting with the application. If the I/O were to block a background thread it wouldn't prevent interacting with the UI.
