I have a FAT32 filesystem mounted. After changing a file on it, I can read the file back and still see the old version. My changes don't actually persist until I unmount and remount the partition. Is this behavior normal? If yes, why does it make sense or why is it needed? Is there a way to set it up so changes appear automatically?


The linux, just like most other operating systems, do cache the disk IO operations. You could force the kernel to flush its buffers with sync command after you performed a file modifications. However, this degrades the performance of the whole system as all currently 'dirty' buffers are flushed to the disks with this command. Alternatively, you could use the fsync C library function to flush the changes you just made to some particular file, but this function does not guarantee that the whole filesystem will be in consistent state on the media.

  • Sadly, sync didn't make any difference. – Karolis Juodelė Feb 19 '13 at 17:15
  • 1
    Generally, this is not a good idea at all to make the modifications to the files on fs and read its raw partition at the same time. The only method to make the fs image or partition completely consistent is to unmount it. – Serge Feb 19 '13 at 17:30
  • Okay, I guess I'll get used to mounting then. Why is this though? To prevent corruption? – Karolis Juodelė Feb 19 '13 at 17:43
  • No. As soon as you have root access nothing is able to prevent you from corrupting your system. However most regular tools are at least warns you when you try to do something with a mounted fs. The reason for such behavior is performance. However, you could try the sync and dirsync options with mount as the other answer suggests – Serge Feb 19 '13 at 17:49

You might be able to find the old version of the same file even after unmounting it, as a filesystem does not necessarily have to store the new file in the same place. So a new file does not necessarily overwrite the old one, if it's stored in another free location.

Changes you make in a filesystem are not immediately written to disk due to performance reasons. Why make programs wait until a file has actually been physically written out completely, when you can just as well have the OS do it in the background? Sometimes this asynchronous behaviour can even save writes altogether, such as when a file is deleted or overwritten immediately after creation, it never needed to be physically stored in the first place.

You can disable that behaviour for most filesystems using the sync mount option. There is also the sync command which forces data to be written to disk without umounting.

You should never access a filesystems raw data though. If you have /dev/sdb1 mounted and then use another machine to mount the very same filesystem (over a network block device or whatever), so two systems work with the same filesystem data at the same time, you'll end up with corruption. Only special (cluster) filesystems work that way; for all others you need a network filesystem (where only one machine mounts the disk, and exposes its files transparently over the network).

  • sync doesn't seem to help. The reason I need to access raw /dev/sdb is that I'm testing a toy file system reader (of a toy OS). – Karolis Juodelė Feb 19 '13 at 17:26
  • With LVM you could do snapshots. Ideally a snapshot is synced properly and frozen in place so it should give you a consistent view. Accessing a read-write mounted device will just lead to corruption as its state is undefined/changing, hence the need to fsck after unexpected power failure. What is on the device does not have to be complete or usable as long as it's still mounted. – frostschutz Feb 19 '13 at 20:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.