KDL after unmounting an image file on a partition that is mounted read-only

[taos]

In hrev37573, a fat32 partition is mounted read-only by default. If you mount an image file (e.g. haiku-nightly.image) on this read-only partition by double-clicking and you subsequently try to unmount the image file via the right-click context menu, you'll visit kernel debugger land (see attached syslog_short.txt). After leaving KDL you have to force-unmount the fat32 partition.

If the fat32 partition is instead mounted with read and write access, you can mount and unmount image files (that afaik are always mounted with write access by default) without a problem. The fat32 partition can also be unmounted in the normal way.

It would be nice if Haiku would prevent you from mounting an image file on a read-only partition by a simple double-click or if Haiku would at least show a warning. Entering KDL could be a little irritating for an unexperienced first-time user of Haiku.

[anevilyak]

That appears more likely to be either a BFS or VFS bug, not really FAT specific. Assigning to kernel for now since it appears to have mounted BFS as read-write on the image file (or at least the fact that it's trying to write back journal blocks seems to imply as much).

[bonefish]

Neither file system seems to bother to check whether the underlying device is writable. Both would need to to make this work. Or this could be handled in ​fs_mount(), which would be the easiest way. It's just a question of defining the semantics: Should it fail when B_FS_IS_READONLY is not given in such a case, or should it silently add the flag?

[jackburton]

Replying to bonefish:

Neither file system seems to bother to check whether the underlying device is writable. Both would need to to make this work. Or this could be handled in ​fs_mount(), which would be the easiest way. It's just a question of defining the semantics: Should it fail when B_FS_IS_READONLY is not given in such a case, or should it silently add the flag?

Couldn't it add the flag and return the information in some way ? Otherwise, it'd be up to the user (the api user) to check the actual flags against the requested mount flags, after the call to fs_mount().

[axeld]

Why can the second file system open the image file read/write in the first place? This is what BFS checks for, and it will fall back to read-only if it couldn't open it read/write.

[bonefish]

Replying to axeld:

Why can the second file system open the image file read/write in the first place?

Apparently because dosfs_open() ​does things incorrectly.

This is what BFS checks for, and it will fall back to read-only if it couldn't open it read/write.

Ah, indeed, I first missed that. If every file system with write support did that (FAT doesn't for instance), that would work well enough.

[taos]

A BFS image file on a read-only ext3 partition is - as desired - automatically mounted by double-clicking as read-only. So, in contrast to read-only fat partitions, unmounting the image file doesn't result in KDL (see attached syslog_ext3_short.txt). There's just one minor nuisance: After unmounting the image file you can only force-unmount the ext3 partition.

[jonas.kirilla]

In hrev39648, opening a BFS image (resulting in it getting mounted) on a non-boot BFS partition and then unmounting the image, results in the host partition not being cleanly unmountable. The "force unmount" dialog comes up. (It doesn't matter if the host volume is mounted as read-only or read-write.)

[taos]

Using hrev48099, I can no longer reproduce KDL when unmounting an BFS image file on a read-only FAT32 partition (there's still the "force unmount" dialogue). However, since the image file is still mounted as read/write you can provoke a visit to KDL by trying to create a new folder in the mounted image file. Photo of KDL is attached.

[taos]

KDL after "creating" a new folder in a mounted BFS image on a read-only FAT32 partition.

[axeld]

It's still the same issue. In any case, this panic is not a real panic, ie. it mustn't end up in a non-alpha release. Thanks for the reminder in any case :-)

[waddlesplash]

Still an issue?

[waddlesplash]

The "could not write back block" panic was removed and now should be somehow propagated.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone