Casper only scans vfat filesystems for cow files

This bug was fixed in the package casper - 1.132

---------------
casper (1.132) intrepid; urgency=low

  [ Colin Watson ]
  * Switch default unionfs implementation to aufs.

  [ Agostino Russo ]
  * Do not scan only vfat volumes when looking for cow devices (LP: #230703)
  * Allow casper to use a squashfs filesystem within an arbitrary path (LP:
    #230716, #207137)

 -- Evan Dandrea <email address hidden> Wed, 28 May 2008 15:01:30 -0400

Accepted into -proposed, please test and give feedback here

Tollef Fog Heen points out on IRC that this is a potential data loss regression:

 < Mithrandir> slangasek: mounting file systems will always cause the journal to be replayed, something which can cause data loss if the file system is in use by a hibernated system.
 < Mithrandir> so, hibernate, boot live cd, boom, instant file system corruption.
 < Mithrandir> luckily only if you try to use it with persistence enabled, it seems.

This may be considered an acceptable risk going forward, but is an inappropriate change in an SRU. Please drop ext3 from the list of filesystem types to scan.

Why not just mount without replaying the journal then?

Mount has an ext3 specific option, 'noload':

       noload Do not load the ext3 file system’s journal on mounting.

This is a really, really bad idea; it can easily cause data loss in the following scenario:

Machine hibernates, user boots an Ubuntu live CD which then proceeds to scan all partitions. Doing this causes the journal of the root partition of the suspended system to be replayed. Later, the hibernated system is resumed without it noticing that the journal having been replayed. This causes file system corruption.

Hmm wouldn't the same issue affect hd-media/iso-scan then? And lupin... In fact any dual boot setup sharing the same partition is potentially vulnerable (unless I misunderstood).

Agostino: yes, it is a real problem elsewhere, and I'm pretty sure there are bugs about it. That doesn't justify introducing the same bug here, in a much more widely used case. Far more people use the Ubuntu live CD than the other cases you mentioned, and it is extremely important that it not trash the system by default.

In the case of hd-media or wubi installations, while it's still a bug, at least you're expecting to perform an installation and it's much more likely that you'll shut down the computer properly first. Hibernating and booting a live CD is a much more plausible real-world scenario than either hibernating and performing a USB stick installation or hibernating and performing a Wubi installation.

This change should be reverted, and a comment should be added above the code in question to indicate that it must not be modified to include any filesystem type that might be able to mount a journalled filesystem, so that we don't forget this in future.

See also bug 41624.

I reverted the changes in the hardy.proposed branch

Please get the reverted patch uploaded to hardy-proposed. ATM we cannot move the current hardy-proposed package into hardy-updates.

This has been accepted now into hardy-proposed.

This change was reverted in intrepid in the same way, so syncing up the states to Won't Fix.