I believe that it’s due to how the kernel “caches” and “buffers” the drive. It completes the operation sooner (to the program) while the kernel is still writing it to disk. It seems there is a way to turn it off, but I haven’t tested this:
I’m no developer when it comes to hardware, kernel or the file manager, but seeing as 18.04 has the feature, I’m not sure if 16.04 will receive any updates in this area without risking stability as a Long Term Release (LTS).
It could be the kernel version – v4.4 is the one from 16.04 originally, but can be upgraded to v4.10 (and later) with the LTS Enablement Stack.
That said, I’ve yet to have any corruption issues with USB drives, and I’m still rocking 16.04. Instead I observe my system’s resources using indicator-multiload (MATE has a similar applet called System Monitor too) and so if I eject from the file manager, I can usually see there is still some disk write activity and then the RAM (buffer/cache) usage goes down.
If it just happens to one drive, there is a possibility the medium itself is corrupted. I’ve known this with a bunch of old floppy disks Even after successfully letting it write and flushing the cache/buffer (without ejecting):
sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
The file ended up corrupted, checksums didn’t match.