Argthtjtr

In Windows, you can normally "eject" a USB storage device before physically unplugging it to avoid data corruption.

However, for some devices Windows does not provide an "eject" option. I've seen this most frequently with some smart phones.

Why is this?

Probably because the method that is used to transfer files to phones (MTP rather than USB Mass Storage) puts the onus of data and filesystem integrity on the device receiving the data, which in the case of mobile phones also is presumed to be smart and self-powered or have battery back up.

USB mass storage devices are usually dumb memory sticks or hard drives, MTP devices such as phones, cameras and similar are generally reasonably smart devices which handle their storage personally. As such the file transfer can happen in a peer-to-peer ideology rather than a smart-host-dumb-client one. Once the data is "sent" to the phone it is up to the phone operating system and filesystem methods to ensure correct storage of the file.

If the file transfer is interrupted and thus partially transferred then the phone can decide whether to free up any allocated space or show what was transferred on a case-by-case basis. I suspect most interrupted transfers will simply drop incomplete data and free any allocated blocks. Filesystem integrity is actively managed by the phone.

As such a transfer either happens or it does not and doing a software eject is unnecessary, the only reason to have it is so that the person using the computer can get that "I'm done" warm glowy feeling. USB certainly doesn't need it from a hardware perspective and is quite happy with hotplugging devices.

From the MTP Wikipedia page:

A main reason for using MTP rather than, for example, the USB mass-storage device class (MSC) is that the latter operates at the granularity of a mass storage device block (usually in practice, a FAT block), rather than at the logical file level. In other words, the USB mass storage class is designed to give a host computer undifferentiated access to bulk mass storage, such as compact flash, rather than to a file system, which might be safely shared with the target device (except for specific files which the host might be modifying/accessing). In practice, therefore, when a USB host computer has mounted an MSC partition, it assumes absolute control of the storage, which then may not be safely modified by the device without risk of data corruption until the host computer has severed the connection. Furthermore, because the host computer has full control over the connected storage device, there is a risk that the host computer may corrupt the file system, reformat it to a file system not supported by the USB device, or otherwise modify it in such a way that the USB device cannot completely understand it.

Summary

This is ultimately a matter of whether the device uses MSC or MTP/PTP. As a rule, dedicated storage devices like flash drives and external hard drives use MSC, while smartphones and other devices which need to maintain access to the data while connected to a computer or require control over the data transferred will use MTP. Many cameras use PTP, a subset of MTP.

If the device uses MSC, you'll need to eject it from the computer before you can remove it. If it uses MTP or PTP, ejection is not required.

Technical details

The Mass Storage Class (MSC) allows the computer to communicate with the drive in much the same way it would with an internal hard drive or SSD, making it faster than other protocols for transferring data. This is what dedicated storage devices like USB flash drives and external hard drives use. However, it requires block-level access to the underlying storage media, and that means exclusive access to the device. As a result, MSC is not okay for smart devices because they need to be able to access the contents of the filesystem while the computer is using it. A smartphone would effectively need to shut down its OS before it can grant block-level access to a computer—a cumbersome procedure, and one that would prevent you from running apps or otherwise using the device while it is connected. It is the computer's responsibility to ensure that the data has been completely transferred, so you need to tell the computer that you're done by ejecting it.

Media Transfer Protocol (MTP), which is what most smart devices use, involves file-level access, and the device, not the host computer, is responsible for managing the data. Smartphones use MTP because they need to be able to access the data while the device is connected to a computer. MTP also permits the device to control or limit what data can be transferred; some (primarily older) digital media/MP3 players use MTP to enforce copy protection (DRM) on files transferred or to ensure that the media files transferred are compatible with the device. As MTP simply presents a hierarchical file/folder structure, the computer does not need to worry about the filesystem or how the device stores data. In any case, with MTP, there is no need for an explicit eject command; once the device tells the system that the transfer is complete (the progress dialog has closed), you can remove the device without explicitly ejecting it.

MTP is a superset of Picture Transfer Protocol (PTP), which was originally designed for cameras communicating with computers. Many cameras still use PTP, but some support MSC, and some allow a choice between MSC and PTP. Furthermore, some cameras support direct printing through a protocol known as PictBridge, which requires PTP. As with MTP, PTP does not require an eject command. Whether a camera can use MSC, PTP, or both depends on how the camera handles its storage while connected to a computer.

Note that if you remove the memory card from a camera and insert it into an SD card slot or other media reader on your computer, it'll be an MSC device and you'll need to eject it when you're done transferring pictures.

The design is also related to how devices are powered.

Where both devices have their own energy source, for example the computer and the smartphone, there is sufficient space to implement proper handling of transfer interruptions or any other failure. The design relies on the power continuously available and that is stable factor which allows to make the other factor (communication) fault-tolerant. Without it, in exceptional case, for example if battery is suddenly removed from the smartphone or the PC is forcibly powered off, these devices and their systems are actually no more error-resistant than dumb USB drives. (chkdsk anyone?) Those fault-tolerant devices just rely on enough time to gracefully resolve expected problems.

But devices powered from their host have small to none time for any reaction to disconnection from their power. And hosting a file system in such a device means not only serving user requests, but also availability to background reads and writes made by host background processes unknown to the user. User never knows if the communication is happening at the present moment. So there must be provided an explicit way of signaling of the intent of powering down (and it is that Eject command) upon which the host has to cease from any operations. Sudden power disconnection is then awaited without a risk. So "Eject" event is a simple way to start proper finalization while we still can rely on continuous operation. And the substance is now not different from the above case: power is granted during all the necessary actions. When finished, the host signals back (because it is the user who physically controls power interruption) that now it is safe to suddenly interrupt device's power without the risk.

So we see that one of most significant design-driving factors is whether the device is capable of running autonomously to have a time for handling failures or not. If not, prior explicit finalization has to be requested – by the Eject command.