How to detect flash drive removal

This program writes to a file in a flash drive, but the write operation succeeds even after removing the drive:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
   char buffer[26] = "USB mass storage test4.\r\n";
   FILE *file_pointer = NULL;
   char *my_file = "/media/sda/mydata.txt";
   size_t len = 0;

   file_pointer = fopen(my_file, "a");
   if (file_pointer != NULL)
   {
      len = strlen(buffer);
      if (fwrite(buffer, len, 1, file_pointer)!=0)
      {
         fflush(file_pointer);
         fclose(file_pointer);
         sync();
         printf("Data written to the file.\n");
      }
      else
     {
        printf("Zero bytes written to the file./n");
      }
   }
   else
   {
      printf("Error opening the file.");
   }
   return 0;
}

If I remove the drive, I can still open the file and write to it at /media/sda. How can the program detect that the device is no longer available?

Related question - why does the same drive sometimes attach as disk-1, disk-2, disk-3, etc. rather than as sda?

Jan

Welcome to the wonderful world of caching. Linux caches reads/writes
to storage devices, so if you pull a removable drive without syncing
and unmounting then the cache doesn't know that the device is gone. In
linux one should always do a proper unmount prior to removing a USB
attached storage device. When you do that the file access will fail
because the path no longer exists.

I suppose there's an argument to be made that the USB storage drivers
should behave differently than permanently attached storage devices.
Ideally the driver would always flush the cache and automatically
detect and unmount when the device is pulled, but at the moment they
don't so that's what we're stuck with.

Eric

There is synchronous mounting (sync option) that some distros use
by default that will partially alleviate the caching. A similar
effect can be done via O_SYNC. Then there are hooks to the kernel
for notifications, i.e. what udev uses.

So the exact behavior can be changed in many ways.Detecting
removal is only part of it and that can be done but if the real
problem is limiting dataloss, synchronous writes would also be
needed.

It is an interesting problem. Although it doesn’t concern BeagleBoard as such. My team is creating a new linux distribution. I’d love to see this getting solved in one way or the other.

How does OS-X solve it? It is unix underneath. It gives me a warning anyway, but the content isn’t really lost. All of it is usually flushed.

Does this need a change in the file-system driver?

There is synchronous mounting (sync option) that some distros use
by default that will partially alleviate the caching. A similar
effect can be done via O_SYNC. Then there are hooks to the kernel
for notifications, i.e. what udev uses.

Thanks to all for the comments.

To be clear, the caching of writes to attached drives isn't the problem; calling sync speeds that up if needed. What troubles me is being able to open and "write" to a file on a drive that is long gone. For example, a data logger might store its data on a flash drive. If the user removes the flash drive, the firmware will continue to write to the file at /media/sda.

I tried placing this rule in a file in /etc/udev/rules.d to force an unmount, but it didn't help:

DEVNAME=="/dev/sda"
SUBSYSTEM=="block", ACTION=="remove", RUN+="/etc/udev/scripts/mount.sh"

(mount.sh appears to handle both mounting and unmounting)

How can firmware detect drive removal so it can take action such as advising the user to attach a drive?

Jan

Jan Axelson <jan@lvr.com> [2010-08-13 16:49:21]:

Hi,

How can firmware detect drive removal so it can take action such as
advising the user to attach a drive?

I'm checking /proc/mounts for the flash drive existence, just before I try to
store something on the flash drive.

-- ynezz

> How can firmware detect drive removal so it can take action such as
> advising the user to attach a drive?

I'm checking /proc/mounts for the flash drive existence, just before I try to
store something on the flash drive.

That's helpful, thanks!

Jan