Storage Management, is there any plan?

[zydon]

Question:
I haven't seen any built-in tools that could be used by user to handle storage management in ReactOS. Something equivalent to Scandisk, Defrag, Partition Manager and CHKDSK hasn't been planned into the Roadmap. Is there any chances we could see them in any next version Roadmap?

Reason:
As a user/consumer of any OS would had this first in their mind when using any new OS. The should provide a sets of built-in tools to handle the storage file system whatever it was used by the OS. The main reason the OS being choose is because it can manage the storage well and has a tools to do the trouble-shooting when any problems occurred with the device.

Thanks in advance.

[PurpleGurl]

They are not mentioned, but they should be included. Windows has Scandisk and Defrag, as well as Disk Management. In Windows, Disk Management is a Management Console snap-in, so finishing the Management Console and filesystem work would have to come first. While Scandisk should be built-in, many prefer to use their own choice of defragger. I like Defragler since it is good for spot defragmentation when you don't want to do the entire volume (though it can do that too).

[fred02]

many prefer to use their own choice of defragger. I like Defragler since it is good for spot defragmentation when you don't want to do the entire volume (though it can do that too).

Agreed. UltraDefrag is another good choice, if FOSS is important.

While Scandisk should be built-in

I would say it is more of a responsibility of the FS developer/provider, since it will not be the same for NTFS as for ext2 etc. ROS need only providing chkdsk for the FSes it will be supplied with. As of now, it would be FAT/FAT32.

[mrugiero]

I don't know about Defragler, but all of the defragmenters I know (this includes UltraDefrag) relies on Windows APIs for defragmentation. The infrastructure needs to come with ReactOS, even while the frontend might not be needed.

[PurpleGurl]

I don't know about Defragler, but all of the defragmenters I know (this includes UltraDefrag) relies on Windows APIs for defragmentation. The infrastructure needs to come with ReactOS, even while the frontend might not be needed.

There is one exception, and that is offline defraggers. Since they use DOS, Linux, or a custom OS to do things outside of Windows. The NTFS structures cannot be moved while in use, and all versions of NT have a FAT32 folder handling bug, and thus no defragger for NT/2000/XP will try to defrag directory entries themselves. The closest workaround is to defrag, create and rename folders and move contents between them, and defrag again. Defragler uses some sort of work around for FAT32 folder handling, but it can only defrag them to 2 fragments. Otherwise, it has to be done outside NT, like when I used to run 98 and 2000 on the same machine. I used 98 for things 2000 would not do, like fully defrag a FAT32 volume and rip media (via an OS patch, though XP does have this built in).

And yes, the APIs need to be included. Z98 and I went around around the FAT32 APIs. We locked in the discussion. He said we should make it the same way as on XP, bugs and all. I said there was no reason not to fix it since any responsible defragger would not use the particular API in question, and he said if that was the case, perhaps it would not need coded at all. However, I don't see why we can't have a few ROS-specific apps if what is need to make them work does not impact NT compatibility. But right not, that is very trivial since NT has had that bug for years and Microsoft never saw need to fix it (hey, they have NTFS, so no need to waste the time since their FAT32 support works good enough for migration purposes). While it can be a performance issue, it is something that NT can work fine without addressing.

[erkinalp]

I don't know about Defragler, but all of the defragmenters I know (this includes UltraDefrag) relies on Windows APIs for defragmentation. The infrastructure needs to come with ReactOS, even while the frontend might not be needed.

And yes, the APIs need to be included. Z98 and I went around around the FAT32 APIs. We locked in the discussion. He said we should make it the same way as on XP, bugs and all. I said there was no reason not to fix it since any responsible defragger would not use the particular API in question, and he said if that was the case, perhaps it would not need coded at all. However, I don't see why we can't have a few ROS-specific apps if what is need to make them work does not impact NT compatibility. But right not, that is very trivial since NT has had that bug for years and Microsoft never saw need to fix it (hey, they have NTFS, so no need to waste the time since their FAT32 support works good enough for migration purposes). While it can be a performance issue, it is something that NT can work fine without addressing.

One exception too: ReactOS' own defragmenter- it can use the fixed FAT32 defragmention funcions.

[PurpleGurl]

One exception too: ReactOS' own defragmenter- it can use the fixed FAT32 defragmention funcions.

That is what I was suggesting. I don't know if there is any software or Windows functions that depend on that API being broken as it is. If there is, a private new one could be added.

[zydon]

It would be nice if the ROS Hard Disk partitioning and formatting routines in the installer become the base API for ROS reading the hard disk partition and limited formatting feature just for a diskette, USB key or virtual diskette for a start.

I like the idea of the ROS very own CHKDSK too. At least there some information for user to know their disks status before the improved version that capable to fix some error on the disks.

[PascalDragon]

One exception too: ReactOS' own defragmenter- it can use the fixed FAT32 defragmention funcions.

That is what I was suggesting. I don't know if there is any software or Windows functions that depend on that API being broken as it is. If there is, a private new one could be added.

Even then one could use the Shim approach once it's implemented in ReactOS (Note: I'm not talking about "implement it now!", but more like "somewhen in the future"): A program that relies on the broken behavior could get a Shim loaded that provides this broken behavior and all other programs could use the corrected API.

Regards,
Sven

[PurpleGurl]

That is what I was suggesting. I don't know if there is any software or Windows functions that depend on that API being broken as it is. If there is, a private new one could be added.

Even then one could use the Shim approach once it's implemented in ReactOS (Note: I'm not talking about "implement it now!", but more like "somewhen in the future"): A program that relies on the broken behavior could get a Shim loaded that provides this broken behavior and all other programs could use the corrected API.

Regards,
Sven

I wasn't thinking about that. Then it could be implemented correctly and then exceptions could be made via a compatibility manager and/or a table in the registry. I doubt the incorrect behavior would be necessary since most defragger writers would know about the FAT32 folder handling bugs under NT systems. So if they were run on ROS, they wouldn't even touch the correctly working function. So they shouldn't change in how they operate. I know it is outside the scope of the project, but it wold be nice if those who wrote existing tools could support the correctly implemented API. They would have to know it was ROS they were running on. They could test for sizes or CRCs of certain files or something. The disadvantage would be if they had to recode that data each time we updated that file.

We discussed before about the dilemma of modifying some functionality and letting certain programs know. Obviously, we'd have to disclose the version data in the same way that Windows does and report a known version number. But then, how would the other software know if it is safe to ask if it is running on ROS or not? I think someone said a subversion could be added. It could maybe report an unofficial subversion. My initial idea was a registry entry, but that obviously presents two problems - our key being present under Windows or missing under ROS, and leading to unpredictable behavior.

Oh, and there are some places where there needs to be incompatibility, such as Windows Update. But I imagine that will be default behavior since we obviously cannot support WGA nor Windows update. Plus we might want to manage updates differently for whatever reason. Obviously, it would have to call home to ROS and not to Microsoft.

[erkinalp]

We discussed before about the dilemma of modifying some functionality and letting certain programs know. Obviously, we'd have to disclose the version data in the same way that Windows does and report a known version number. But then, how would the other software know if it is safe to ask if it is running on ROS or not? I think someone said a subversion could be added. It could maybe report an unofficial subversion. My initial idea was a registry entry, but that obviously presents two problems - our key being present under Windows or missing under ROS, and leading to unpredictable behavior.

I suggested identifying ReactOS as NT5.3. But Ziliang refused that(see the next message after mine)

[PurpleGurl]

I suggested identifying ReactOS as NT5.3. But Ziliang refused that(see the next message after mine)

Yes you did and I agreed, and this line of discussion does fit better over there.

Anyway, we should include the basics of disk management. In older versions of Windows, that was a disk checker and a defragger, but in XP and I presume newer, there is partition management too where you can rename drive letters, create and delete volumes, mount and unmount disks (particularly necessary if you have over 25 volumes), etc. We would not be able to add the more advanced features until we include NTFS. Doing JBOD and RAID in software would require the ability to create reparse points.

[erkinalp]

No, single registry entry will suffice for a mount point even in a FAT FS, with different semantics though. You know that kernel does not use the drive letters internally, they still remain because programmers of Windows ME applications wanted so.

[PurpleGurl]

No, single registry entry will suffice for a mount point even in a FAT FS, with different semantics though. You know that kernel does not use the drive letters internally, they still remain because programmers of Windows ME applications wanted so.

I mean being able to fake at JBOD/RAID stuff using the OS to do it (rather than drivers or dedicated hardware) is what require reparse points unless my understanding is off. I specifically mentioned reparse points because they allow you to have hard links from one volume to another volume. Some of the other stuff I mentioned can be done in the registry or the MBR. 2000 did some things in the MBR, and I remember using 98 and 2000 on the same machine (I left 98 on there for a couple of reasons, being able to rip CDs without software - change one system file, and being able to defrag and internally sort directory entries). But 2000 handled drive letters differently and sometimes they would be out of order in 98. So I would issue FDISK /MBR to remove logical ordering and default to the physical order (also helped remove certain viruses under DOS, though Microsoft put that in there initially to remove custom boot messages they would insert during installation).

And yes, I understand how the drives are addressed internally using adapter addresses and port addresses. However, not all software can address things that way. For instance, there is NTRegOpt. It is a registry packer (internal defragger, not a cleaner) in that it reads the entire registry, writes to new files, then activates them on reboot. But you can have problems under certain situations in Windows 7 and 8. One being problems due to UAC, which is easy to get around. Another is when the registry hives are on a hidden volume (which is not a bad idea, BTW). The way around that would be to assign that volume a letter so the program can find the hives.

[PascalDragon]

No, single registry entry will suffice for a mount point even in a FAT FS, with different semantics though. You know that kernel does not use the drive letters internally, they still remain because programmers of Windows ME applications wanted so.

I mean being able to fake at JBOD/RAID stuff using the OS to do it (rather than drivers or dedicated hardware) is what require reparse points unless my understanding is off.

No, reparse points are not needed. RAID/JBOD is handled on a lower level (see here).

And yes, I understand how the drives are addressed internally using adapter addresses and port addresses. However, not all software can address things that way.

I prefer to go with \Device\HarddiskVolume1 instead of the adapter and port addresses

Regards,
Sven