Trunk Revision 52678

[SomeGuy]

Well, that is interesting. I created a drive image with one primary partition and eight tiny FAT partitions inside an extended partition. Nothing strange, just used DOS FDISK. Got similar results.

The first (primary), fifth, and ninth partitions are accessible from within ReactOS. The others show up as unmounted "cd drives" in the explorer.

c: (visible in ReactOS as C)
d:
e:
f:
g: (visible in ReactOS as D)
h:
i:
j:
k: (visible in ReactOS as E)

[PurpleGurl]

Well, that is interesting. I created a drive image with one primary partition and eight tiny FAT partitions inside an extended partition. Nothing strange, just used DOS FDISK. Got similar results.

The first (primary), fifth, and ninth partitions are accessible from within ReactOS. The others show up as unmounted "cd drives" in the explorer.

c: (visible in ReactOS as C)
d:
e:
f:
g: (visible in ReactOS as D)
h:
i:
j:
k: (visible in ReactOS as E)

So you get the same thing that I get. Also for me, everything shows up twice. So you see the 3 mounted drives, the 6 unmounted drives, then all that again with the mounted drives in new letters. My guess is that in my case, it has to do with having a RAID 1 set. What I use is a pair of 360 Gb drives. When I build my next system, I will put drives of at least a Tb in. I know that for 2K and XP, you have to have the manufacturer's mass storage driver for SATA/RAID for it to even install. I have a feeling that getting 3rd party drivers to work may need to be a priority. That won't fix this issue in explorer, but I have a feeling that would get rid of a lot of the remaining RAID/SATA incompatibilities and quirks like duplicated drive icons.

[hto]

The first (primary), fifth, and ninth partitions are accessible from within ReactOS. The others show up as unmounted "cd drives" in the explorer.

Fixed in trunk.

[SomeGuy]

I also tried an image with 22 partitions. Indeed the pattern continues, ReactOS is mounting every fourth partition in an extended partition.

Also, ReactOS setup hangs if there are more than 14 partitions. (Yay, another bug)

l:
m:
n:
o: (visible as F)
p:
q:
r:
s: (visible as G)
t:
u:
v:
w: (visible as I)
z:

I'll grab a new build and see what that does in a bit then.

[PurpleGurl]

The first (primary), fifth, and ninth partitions are accessible from within ReactOS. The others show up as unmounted "cd drives" in the explorer.

Fixed in trunk.

Maybe, but I wouldn't know. It seems there is a new regression. It won't accept any PS/2 devices now it seems. I double-checked to make sure legacy support was disabled and even tried disabling USB 2.x just to be sure. But my mouse and keyboard were not recognized.

Now, what I don't understand is how changing that one flag in the code will make the other volumes readable. I won't knock it until I try it, and I hope to be able to try it soon.

[SomeGuy]

For a moment there I thought was just me. It was working just the other day so I took a quick look to see where it broke:

52725 - works
52726 (wont boot)
52727 - no mouse

Broken in VirtualBox, and QEMU.

Filed bug: http://www.reactos.org/bugzilla/show_bug.cgi?id=6387

[PurpleGurl]

For a moment there I thought was just me. It was working just the other day so I took a quick look to see where it broke:

52725 - works
52726 (wont boot)
52727 - no mouse

Broken in VirtualBox, and QEMU.

Filed bug: http://www.reactos.org/bugzilla/show_bug.cgi?id=6387

What I don't understand is what was done to cause that regression. I don't see what the RTL code has to do with it unless I am missing something.

[vicmarcal]

For a moment there I thought was just me. It was working just the other day so I took a quick look to see where it broke:

52725 - works
52726 (wont boot)
52727 - no mouse

Broken in VirtualBox, and QEMU.

Filed bug: http://www.reactos.org/bugzilla/show_bug.cgi?id=6387

What I don't understand is what was done to cause that regression. I don't see what the RTL code has to do with it unless I am missing something.

Underlying bug maybe?

[Haos]

When you try to load a driver, its in general better, to have its path returned in a correct form.

[hto]

Now, what I don't understand is how changing that one flag in the code will make the other volumes readable.

I also tried an image with 22 partitions. Indeed the pattern continues, ReactOS is mounting every fourth partition in an extended partition.

It's because a function which expected to receive an array of valid, recognized partition entries, received all existing entries. That "one flag" sifts wrong entries out.

(As it can be seen from PurpleGurl's dumps, each boot record (MBR or EBR) has 4 entries; the first one describes an NTFS/FAT partition, the second points to the next boot record in the chain (or null for the last record), the others are unused. So, disk "D" corresponds to partition 2, but described by entry 5; etc.)

Those "cd drives" in the explorer were container/unused partitions.

[SomeGuy]

Incidentally, I tested it in revision 52739 and it seems to work great. I created an extended partition with DOS FDISK and I could access files in it from inside ReactOS as drive D. (This revision fixes the mouse/keyboard issues).

Finally I can keep test apps in an extended partition on a single hard drive that won't get zapped when cleanly re-installing ReactOS. (could sort of do that with multiple primary partitions already but DOS/Win9x didn't like that)

Now this opens up a whole world of additional things to test....

Tried installing ReactOS to the extended partition. It installs but setup puts partition #2 in the freeldr.ini when it should be #5. Changing that ReactOS bootstraps the kernel but BSODs with an error suggesting it can't figure out which drive to continue reading from. Well, never worked so it has never been tried before. Unexplored territory!