Opened 12 years ago

Closed 12 years ago

#8090 closed bug (fixed)

KDL from mounting an old Haiku (BFS) filesystem

Reported by: kallisti5 Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: File Systems/BFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

see screenshot of KDL attached. Mounting second partition on a hard drive with two partitions.

gcc4, hrev43152

Attachments (1)

IMG_20111104_151456.jpg (1.6 MB ) - added by kallisti5 12 years ago.

Download all attachments as: .zip

Change History (6)

by kallisti5, 12 years ago

Attachment: IMG_20111104_151456.jpg added

comment:1 by mmlr, 12 years ago

The changes in hrev43033 and hrev43056 are to blame here. On mount the existence of "be:volume_id" is checked, which in case of it not being present at all or not being in the small data section of the root node, will cause an attribute vnode to be created. This however can't work, as the volume isn't yet fully mounted and the volume ops haven't been set yet, causing the VFS to try to access volumeOps->get_vnode on a NULL pointer resulting in the the above 0x10 read (and hence the KDL). A hacky way to get around this would be to initialize the volume ops pointer earlier in bfs_mount, i.e. before the call to Volume::Mount(). It'd probably work as the volume structures are pretty much fully set up in the VFS before calling the actual FS mount, however calling into the VFS with an incomplete mount sounds kind of unclean in any case. Opinions?

BTW: This also happens on boot when installing a new Haiku installation on an existing BFS volume.

comment:2 by axeld, 12 years ago

I think I would just remove the on-mount functionality.

One could either provide a tool to create/change those IDs afterwards. Another option would be to make that check when the root vnode is opened from some application.

comment:3 by Disreali, 12 years ago

Does this mean I need to re-intialize all my BFS volumes if I update to a rev more recent than hrev43033?

comment:4 by axeld, 12 years ago

No, absolutely not. The unique volume ID is a completely optional feature.

comment:5 by mmlr, 12 years ago

Resolution: fixed
Status: newclosed

I've removed that part of the change in hrev43229, which should fix this issue.

Note: See TracTickets for help on using tickets.