Sync really flakey

Hazel v4.0.6
OS X 10.12

I'm having massive problems trying to get a folder to sync.

I'm trying to sync files and folders from one NAS (DSM 6.0.2-8451 Update 1 running EXT4) to a second NAS (DSM 5.2-5644 Update 8 running EXT4). It seems to start okay but after two folders Hazel starts producing a number of folders called (A Document Being Saved By hazelworker x) and if you watch one of these folders you can see Hazel copying across a file and then just deleting it, repeated ad nauseam.

Thanks.

It may be an issue with one or both of the NAS's. As a test, try it with a local folder on one or both ends and see if you can isolate the problem there.

Mr_Noodle wrote:It may be an issue with one or both of the NAS's. As a test, try it with a local folder on one or both ends and see if you can isolate the problem there.

Thanks for the reply. I have done some testing. I spent quite some time logging in and out of network drives and I'm not sure what I might have done but the problem has been partially resolved. There is no longer an issue with Hazel not correctly copying the files and folders across, it completes the task correctly.

However where there is still a fault that Hazel is leaving behind lots of (A Document Being Saved By hazelworker) folders on the destination drive.

They are present when using Hazel to sync folders in the following scenarios:-

NAS1 -> NAS2
NAS2 -> NAS1
NAS1 -> NAS1
NAS2 -> NAS2
MacBook (SSD) -> NAS1
MacBook (SSD) -> iMac (SSD)

It does not occur when syncing from and to folders all contained on my MacBook. So it seems as soon as data passes across the network I encounter this bug. (If I'm initiating Hazel from my MacBook when trying to sync NAS1 -> NAS1 or NAS2 -> NAS2 the data still passes across the network).

Those files are usually generated by the OS/API libraries. Still not sure what situations cause those to stick around, though. What file sharing protocol are you using on the NASes?

Mr_Noodle wrote:Those files are usually generated by the OS/API libraries. Still not sure what situations cause those to stick around, though. What file sharing protocol are you using on the NASes?

SMB3.

I also own Chronosync. I'm trying to move away from CS because I don't need all it's advanced features. My understanding is CS and Hazel both uses rsync and CS works without a hitch. To me that suggests there is something wrong with the implementation of sync in Hazel.

Well, Hazel uses an unmodified version of rsync. It does use the option to try and use temp space on the destination drive. Other than that, maybe there's something different about the conditions when you run Hazel vs Chronosync?

Mr_Noodle wrote:Well, Hazel uses an unmodified version of rsync. It does use the option to try and use temp space on the destination drive. Other than that, maybe there's something different about the conditions when you run Hazel vs Chronosync?

So what information do you need to diagnose the problem?

You can try turning on debug mode: https://www.noodlesoft.com/kb/hazel-debug-mode/

That will log the output of rsync in the logs. Not sure if that will reveal anything but it's worth a shot.

I am also seeing this issue. It appears to have started ever since upgrading to Sierra. I'm copying from my Macbook Pro to a number of FreeNAS zfs network shares.

If you are willing to run a test build, please email support. I have some ideas to test out.

Posting back to say 4.0.7 has fixed this problem. Nice work.

One small point. During a sync one of the files in my destination folder should have been removed because it had been deleted from the source. The file was locked because I was manipulating it. Hazel left behind a single hazelworker folder in the destination. So I would say Hazel didn't deal with the locked file elegantly, not because the locked file was still present (that wasn't Hazel's fault) but it 'forgot' to remove the hazelworker folder. During a normal sync everything works correctly.

Can you post logs? Also, are you syncing the folder containing the file or the file itself?