Folders go inaccessible, could it be write cache settings with USB device in Windows

[lcarver0]

I run FFS version 6.10, x64 in Windows 7 x64. I have been happy with it in the past.
I now use a Seagate Expansion, 1TB disk with my ThinkPad on one of its USB 3.0 ports.
Synchronizing a network-mounted folder (in Windows) to the USB-attached volume.
It writes nicely for a minute or two, and then folders in the attached USB volume stop reading successfully.
In other words, FFS will create a folder, then shortly thereafter it can no longer read or access that folder, since Window tells FFS that the folder does not exist. Which is true, I cannot open the folders in explorer either. Sometimes they appear later on, after waiting a while, but sometimes they never appear at all; which makes me wonder how it is that FFS called a create folder operation, but later the folder does not exist.

I was thinking about write caching of operations; I believe at the start of this, all write caching was disabled to the volume, then I tried enabling it to see whether it could improve this situation; I believe that made it worse.
Right now, in Windows I see: Removal policy option : Better performance i.e. Wnable write caching in Windows. Write-caching policy option : Enable write caching on the device ... and not Turn off Windows write-cache buffer flushing (on the device).
What is a safer policy, in the context of doing a lot of writes to a USB-mounted storage volume from FFS ... Disable write caching on the device, and in Windows ?

The ST1000LM024 (I believe that is what's in my Seagate Expansion portable enclosure) has an 8MB buffer in it ... surely that's not a part of this problem. If there's a real I/O error, or if Windows detects some kind of (software) buffer overrun, surely we'd see a message to that effect?
I have run some basic diagnostic tests on the USB drive, and they seem to indicate it always passes ... and SMART status seems fine. I have a feeling that we're overrunning a queue, somewhere, but I am pretty bewildered about this behavior.
I'll try re-disabling write caching of operations in Windows, and will continue testing.
I have the Windows Event viewer open, maybe something will pop up in there.
Has anyone seen this kind of trouble before?
If it turns out to be a software issue, I think I would prefer that over having an unreliable disk device.

[lcarver0]

Yeah, I see a lot of events in the System event viewer, such as ...
An error was detected on device \Device\Harddisk4\DR18 during a paging operation.
An error was detected on device \...\DR17 during a paging operation.

and now,
An error was detected on device \...\DR24 during a paging operation.

Earlier, when I disabled write caching in Windows (on the volume), it listed this ...
The driver disabled the write cache on device \Device\Harddisk4\DR15.

And I am seeing some of these in the event viewer too, from *Ntfs* (the other errors were from " *Disk* "):
The system failed to flush data to the transaction log. Corruption may occur.

Most of these errors are being listed for DR18 ... I don't know why there are multiple devices; I have just one NTFS partition on it, and the physical device path in Windows is
\Device\00000157

Now FFS stopped with a popup error, finally, but this looks kind of worse:
Cannot copy file ... blah ...
Error Code 21: The device is not ready. (CopyFileEx)

Now I got a different system call symptom (in FFS):
Cannot copy file ... blah ...
Error Code 55: The specified network resource or device is no longer availble. (CopyFileEx)

If I wait a bit, then click the Retry GUI button in FFS, it continues on and is able to continue using the volume.
Ouch; that is clearly nothing to do with FFS, in my mind.

[lcarver0]

I have to assume that the bridge (interface) in my Seagate Expansion is cusing the session to reset ... the session has to reinitiate, which is why that instance number keeps incrementing. Whether this issue comes from hardware (the bridge) or from software, I cannot really say. My motherboard was replaced last Friday (the issue persisted before and after that), that is why I don't believe it's the USB in my ThinkPad that could be causing this.
The other strange thing is that I didn't see these failures when I sync a local volume to a local volume. It only seems to fall over when I sync a network volume to a local volume ... that makes me think that a timing/sequence detail is allowing the I/O paging errors to occur.
I'm going to buy a SATA disk and a new bridge (enclosure), and hopefully that will run cleanly. ( Will return this Expansion, since all I know is that I am experiencing a mysterious problem. )

[Zenju]

> Disable write caching on the device

I'd suggest to always disable caching in Windows for usb memory sticks (= the default), else you'll have to remember to manually "unmount" before pulling out the stick or risk data loss.
For an inherently serial operation such as file copying you don't need caching anyway.

About your problem description: I looks very bad, and from FreeFileSync's perspective all I can say that these are issues outside of the programs control.