Haiku gets confused with 2 volumes with the same name.

[bga]

I have two partitions called "Haiku" I mounted both and changed the name of the second partition to "Empty" and rebooted immediately. After boot both partitions had been renamed empty.

I then proceeded to rename the first partition (boot) back to Haiku and rebooted. The partitions didn't change names (it reset to "Empty") and now the two partition icosn were overlapping which indicates that it also got confused when saving the partition attributes.

I tried yet again and renamed the second partition to "Test". After boot, again both partitions have been renamed "Test".

So it seems that (considering 2 BFS partitions, 1 the boot partition):

1 - Renaming the second partition also renames the boot one (only visible after rebooting). 2 - Renaming the boot partition has no effect and then position attributes on the second partition seeing to be copied to the first partition (also after boot).

This may or may not be related, but I noticed that working with files on the second partition affected files with the same path in the first partition which lead me to believe that there is a general confusion about Volume objects.

[bga]

KDL when rebooting.

[bga]

The KDL capture I just attached was obtained after initializing the second volume and trying to reboot. typing reboot resulted in the "Failed to load OS" message.

[bga]

This is how one can reproduce it:

- jam -q haiku-vmware-image

- Copy haiku.vmdk to empty.vmdk

- Add this to the .vmx file to add the new image:

ide1:0.present = "TRUE" ide1:0.fileName = "empty.vmdk" ide1:0.deviceType = "disk" ide1:0.mode = "persistent" ide1:0.redo = "" ide1:0.startConnected = "TRUE" ide1:0.writeThrough = "FALSE" ide1:0.autodetect = "FALSE"

(this will load the image at the secondary ide channel)

- Boot Haiku.

- Mount the second "Haiku" partition.

Not sure if this is relevant, but when I do this, I get the following error in syslog:

KERN: bfs: KERN: mounted "Haiku" (root node at 262144, device = /dev/disk/ata/1/master/raw) KERN: bfs: volume reports 98192 used blocks, correct is 98526

- In terminal:

cd /Haiku1 rm -rf * cd /boot/beos ls

I got this in Terminal:

ls: reading directory .: Bad data

And this in syslog:

KERN: bfs: InitCheck:301: Bad data KERN: bfs: inode at 786444 is corrupt

Rebooting results in the image being unbootable.

[emitrax]

The question actually is, are two volumes with the same name allowed?

Since the VFS layer contains a few function based on path value, like vnode_path_to_vnode and fd_and_path_to_vnode, having two volume with the same name can perhaps confuse those function.

A little note though: in the rootfs partition, the volume is actually called Haiku1 and not Haiku like it is under the desktop directory. Beside, you can't rename a volume to Haiku as it result in "name already in use" error, which looks like an inconsistency.

[bga]

Yes, you can have 2 volumes with the same name. Otherwise you would have serious problems with removable media.

Yes, the mount point is not related to the disk label at all. The only relationship is that Tracker tries to create a directory with the same name to mount it and then append numbers if the name is already taken.

Anyway, I was only able to reproduce this with VMWare. This may be a VMWare specific bug or it may just be the fact that when trying on real hardware, the partitions are not exactly equal while, with VMWare, they are (I created the second partition as a copy of the first).

[emitrax]

Replying to bga:

Yes, you can have 2 volumes with the same name. Otherwise you would have serious problems with removable media.

What I meant was if it was allowed to mount the volume with the same name already taken by another volume.

Yes, the mount point is not related to the disk label at all. The only relationship is that Tracker tries to create a directory with the same name to mount it and then append numbers if the name is already taken.

In rootfs numbers are appended as you said, but in the Desktop directory they are not.

Anyway, I was only able to reproduce this with VMWare. This may be a VMWare specific bug or it may just be the fact that when trying on real hardware, the partitions are not exactly equal while, with VMWare, they are (I created the second partition as a copy of the first).

I'll see if I can try with a volume with the same name formatted with DriveSetup.

[axeld]

Looks like it's a VMware bug. If I don't copy the image file, but create a new one with the same name manually, the problem does not appear. However, it still seems to happen when I create one image, rename it to empty.vmdk, and then create another. Very weird.

[axeld]

Furthermore, I just tried with Qemu, and it does not expose the bug, even when copying the images. So it definitely is a VMware bug.