The "EJECT" functionality is good because it forces an internal "Dismount" function. On a home system, you never (well... hardly ever) mount or dismount anything explicitly. On a server, there is such a thing as mounting or dismounting a disk. A dismount causes all pending I/O operations to be re-prioritized so that they will finish. Then a forceful close will be imposed on all handles to that device. When the file handle to the drive's root volume (held by the O/S file system) gets closed, the device is dismounted. This is true for USB devices when they are being treated as disk-like storage, because in that case they have been formatted to have a root folder.
The catch is that you need to wait until you get the pop-up that says "It is safe to remove xyz volume from your system." At that point, the root folder should be closed and the drive is fully disconnected from all software. At that time you can pull the thumb drive safely.
ADDENDUM: I apologize for this digression - but it isn't really a digression. Linq's comments about waiting are correct but not complete. This is because of the way Windows manages disks.
Disks have this thing called an "allocation unit" (which on some machines is a disk-cluster). An allocation unit is contiguous and usually aligned with disk geometry so that a complete unit is on the same cylinder and track, and the sector numbers are contiguous. When that happens, Windows can allocate a disk buffer the same size as the allocation unit and can read the whole unit into memory at once. It is no coincidence at all that the Access disk buffer we talk about so often IS the size of a typical allocation unit.
This buffering strategy is called "read-ahead" and saves you physical disk reads. When you ask for a given block of disk, the odds are that you will want the next couple of blocks as well. It works because the disk SEEK operation to find the cylinder costs tens of milliseconds (in a GHz computer, tens of millions of instruction-times) but the disk read is faster, because modern disks are spinning at several thousand RPM, meaning the head is passing over the correct sectors within a couple of milliseconds. That data transfer costs a lot, so the buffering uses memory to save you from needing multiple "rotational latency" times.
The corresponding disk update strategy is called "write-behind" and involves having a "dirty" buffer that is accumulating changes to individual disk sectors, waiting for the program to reach the end of the buffer so it can write out the whole buffer in a single operation. But this is where my discussion returns to the fold. When you are using "write-behind" that means that Windows has intentionally NOT written everything that your program did. Windows is waiting for the buffer to become full.
It applies to Access but even applies to a simple COPY operation. It CERTAINLY applies to Access any time you write something to an external file such as using "TransferToText" or one of the reporting options that writes a report to a PDF or Word or Excel file.
Program exits will trigger what is called I/O rundown, which will trigger forced write-backs of pending buffers. But they are INVISIBLE to you because the program rundown occurs during program EXIT. And programs in rundown are not always visible to Task Manager so you can't check on whether your program is complete. The use of the EJECT function forces the rundowns to finish and then gives you the positive feedback that it is finished.
And of course, for RAM disks, solid-state disks, or zero-rpm-disks (all have been used to describe the same thing) there is NO rotational latency and no seek-arm latency, so those delays of tens of milliseconds become zero. Which is why they are such a fun addition to your system.
