Trunk Revision 52678
Moderator: Moderator Team
Re: Trunk Revision 52678
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)
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)
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Trunk Revision 52678
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.SomeGuy wrote: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)
Re: Trunk Revision 52678
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.
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.
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re:
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.hto wrote:Fixed in trunk.The first (primary), fifth, and ninth partitions are accessible from within ReactOS. The others show up as unmounted "cd drives" in the explorer.
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.
Re: Trunk Revision 52678
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
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
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: Trunk Revision 52678
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.SomeGuy wrote: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
Re: Trunk Revision 52678
Underlying bug maybe?PurpleGurl wrote: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.SomeGuy wrote: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
Re: Trunk Revision 52678
When you try to load a driver, its in general better, to have its path returned in a correct form.
PurpleGurl wrote: Now, what I don't understand is how changing that one flag in the code will make the other volumes readable.
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.SomeGuy wrote: I also tried an image with 22 partitions. Indeed the pattern continues, ReactOS is mounting every fourth partition in an extended partition.
(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.
Re: Trunk Revision 52678
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!
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!
Who is online
Users browsing this forum: Baidu [Spider], Google [Bot] and 25 guests