Opened 9 years ago

Closed 4 weeks ago

#6346 closed bug (fixed)

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

Reported by: taos Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (3)

syslog_short.txt (27.1 KB ) - added by taos 9 years ago.
syslog_ext3_short.txt (2.0 KB ) - added by taos 9 years ago.
IMG_0742-1.jpg (2.9 MB ) - added by taos 5 years ago.
KDL after "creating" a new folder in a mounted BFS image on a read-only FAT32 partition.

Change History (15)

by taos, 9 years ago

Attachment: syslog_short.txt added

comment:1 by anevilyak, 9 years ago

Component: File Systems/FATSystem/Kernel
Owner: changed from nobody to axeld
Type: enhancementbug
Version: R1/Development

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).

comment:2 by bonefish, 9 years ago

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?

in reply to:  2 comment:3 by jackburton, 9 years ago

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().

comment:4 by axeld, 9 years ago

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.

in reply to:  4 comment:5 by bonefish, 9 years ago

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.

by taos, 9 years ago

Attachment: syslog_ext3_short.txt added

in reply to:  description comment:6 by taos, 9 years ago

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.

comment:7 by jonas.kirilla, 8 years ago

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.)

comment:8 by taos, 5 years ago

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.

by taos, 5 years ago

Attachment: IMG_0742-1.jpg added

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

comment:9 by axeld, 5 years ago

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 :-)

comment:10 by axeld, 2 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:11 by waddlesplash, 9 months ago

Still an issue?

comment:12 by waddlesplash, 4 weeks ago

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.