Red Hat Bugzilla – Bug 78401
Files dissapear from floppy disk when dismounted
Last modified: 2015-01-07 19:01:53 EST
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: When a file is created in the first folder of a freshly formatted floppy disk, that file disappears when the disk is dismounted and mounted again. Additionally subsequent attempts to create or copy files in to the same folder generate an Input/Ouput error. This problem does not occur when additional folders are then created on the same disk. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.format a disk and mount it ( I used gfloppy with default options) 2.create a folder then create a file within the folder 3.dismount and re-mount the floppy 4.folder can be viewed but file has gone Actual Results: file has been lost. cannot create new files in this folder. Expected Results: file should be there. Should be able to create additional files. Additional info:
Confirming - I also see this behavior. $ gfloppy <format a floppy disk ext2> $ mount /mnt/floppy $ mkdir /mnt/floppy/foo $ touch /mnt/floppy/foo/bar $ umount /mnt/floppy $ mount /mnt/floppy $ cd /mnt/floppy/foo $ ls -laF total 0 Ironically - if you format the floppy as FAT - no such problem occurs. "bar" appears without a hitch. Do this by repeating the steps and selecting "FAT" instead of ext2. Here's another weirdism - need to figure out where to file this bug. Apparently, once you've done all the above, the floppy refuses to take an ext2 file system (or at least appears to): $ umount /mnt/floppy $ mke2fs /dev/fd0 mke2fs 1.27 (8-Mar-2002) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 184 inodes, 1440 blocks 72 blocks (5.00%) reserved for the super user First data block=1 1 block group 8192 blocks per group, 8192 fragments per group 184 inodes per group Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 33 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. $ mount /mnt/floppy/ $ mount | grep floppy /dev/fd0 on /mnt/floppy type vfat (rw,nosuid,nodev,user=myohe)
Further analysis: $ umount /mnt/floppy # mount -t ext2 /dev/fd0 /mnt/floppy $ mount | grep floppy /dev/fd0 on /mnt/floppy type ext2 (rw) $ cd /mnt/floppy $ ls -laF total 17 drwxr-xr-x 3 myohe myohe 1024 Nov 22 10:52 ./ drwxr-xr-x 8 root root 4096 Nov 12 12:42 ../ drwx------ 2 root root 12288 Nov 22 10:52 lost+found/ $ md bar $ cd bar $ touch foo $ ls -laF total 2 drwxr-xr-x 2 myohe myohe 1024 Nov 22 10:56 ./ drwxr-xr-x 4 myohe myohe 1024 Nov 22 10:56 ../ -rw-r--r-- 1 myohe myohe 0 Nov 22 10:56 foo $ cd /mnt # umount /mnt/floppy $ mount /mnt/floppy $ mount | grep floppy /dev/fd0 on /mnt/floppy type vfat (rw,nosuid,nodev,user=myohe) $ ls -laF /mnt/floppy total 11 drwxr-xr-x 2 myohe myohe 7168 Dec 31 1969 ./ drwxr-xr-x 8 root root 4096 Nov 12 12:42 ../ $ touch /mnt/floppy/f $ ls -laF /mnt/floppy/f total 11 drwxr-xr-x 2 myohe myohe 7168 Nov 22 10:59 ./ drwxr-xr-x 8 root root 4096 Nov 12 12:42 ../ -rwxr-xr-x 1 myohe myohe 0 Nov 22 10:59 f* $ cd /mnt $ umount /mnt/floppy $ mount /mnt/floppy $ ls -laF floppy total 11 drwxr-xr-x 2 myohe myohe 7168 Dec 31 1969 ./ drwxr-xr-x 8 root root 4096 Nov 12 12:42 ../ -rwxr-xr-x 1 myohe myohe 0 Nov 22 10:59 f* $ umount /mnt/floppy # mount -t ext2 /dev/fd0 /mnt/floppy $ mount | grep floppy /dev/fd0 on /mnt/floppy type ext2 (rw) $ ls -laF /mnt/floppy/ total 18 drwxr-xr-x 4 myohe myohe 1024 Nov 22 10:56 ./ drwxr-xr-x 8 root root 4096 Nov 12 12:42 ../ drwxr-xr-x 2 myohe myohe 1024 Nov 22 10:56 bar/ drwx------ 2 root root 12288 Nov 22 10:52 lost+found/ Sounds like a SERIOUS bug...
Also discovered that the problem does not arrise when using mke2fs to format the disk. Suggests that the issue is with gfloppy.
What could gfloppy do that could possibly corrupt the disk so badly? I would have to say that the severity should by high since loss of data can occur.
Severity changed to high due to possibility od loosing data.
Ah, looks like a known problem when formatting disks of all sorts. Basically, the problem is that different filesystems put their critical metadata in different places. For ext2, the superblock starts at offset 1024 into the filesystem. For msdos (and hence vfat), it starts at offset 512. So if you have a disk formatted as vfat, and then reformat it as ext2, the old vfat superblock may still be there just before you get to the ext2 one. mke2fs has got this right since version 1.24, though, and will clear the remnants of the old dos filesystem in those versions (which explains why mke2fs doesn't show the problem, only gfloppy.) Reassigning to gfloppy.
gfloppy just calls mke2fs directly. Am I missing an option to it? 8.0 shipped e2fsprogs 1.27, so it should be recent enough, right?
Please verify this with a newer version of Red Hat Enterprise Linux or Fedora Core and reopen it against the new version if it still occurs. Closing as "not a bug" for now.