Most recent kernel where this bug did not occur: not known Distribution: Hardware Environment: Software Environment: Problem Description: ISO image with some offset mounts at REGULAR file. Steps to reproduce: $ dd if=some-image.iso of=IMAGE.iso bs=4096 seek=18 # mount -t iso9660 -o loop IMAGE.iso /mnt/<directory> mount: Not a directory # mount -t iso9660 -o loop IMAGE.iso /mnt/<regular_file> # mount | grep IMAGE.iso /<path>/IMAGE.iso on /mnt/<regular_file> type iso9660 (rw,loop=/dev/loop1) # ls -l /mnt/<regular_file> -r-xr-xr-x 1 root root 0 Янв 1 1970 /mnt/<regular_file>
Sorry, for not ASCII symbols in the last line. # LC_ALL=C ls -l /mnt/<regular_file> -r-xr-xr-x 1 root root 0 Jan 1 1970 /mnt/<regular_file>
So, this corrupt(?) iso9660 image is exporting a root file instead of a root directory. That's why you can mount it onto a file (but not onto a directory). In isofs_read_inode: if (de->flags[-high_sierra] & 2) { inode->i_mode = S_IRUGO | S_IXUGO | S_IFDIR; inode->i_nlink = 1; /* Set to 1. We know there are 2, but the find utility tries to optimize if it is 2, and it screws up. It is easier to give 1 which tells find to do it the hard way. */ } else { /* Everybody gets to read the file. */ inode->i_mode = sbi->s_mode; inode->i_nlink = 1; inode->i_mode |= S_IFREG; } we go down that 2nd path and don't flag this inode as a directory. I'm not sure why this zero-padded ISOFS image even mounts - I don't know enough about iso9660 format....
Nikolaj, any update on this problem please. Have you found what was wrong with the image? Thanks.
(In reply to comment #3) > Nikolaj, any update on this problem please. Have you found what was wrong > with > the image? > Thanks. The original some_image.iso -- NOT corrupted. You may do these steps with any right image to reproduce it.
Yes, I could reproduce it as well. I'm curious, how on earth did you ever stumble upon this reproducer? :) -Eric
Any updates on this problem, is it still there or has been resolved?