Disk Drives vs. Mount Points ?.

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
alexsunny123
Posts: 2
Joined: Fri Jan 15, 2021 4:54 pm

Disk Drives vs. Mount Points ?.

Post by alexsunny123 »

Hello,

Windows-versions inherit the odd system of disk drive letters from the old CP/M

Unix-versions (Solaris, Linux, BSD, BeOS, MacOS X, NextStep, ...) don't have this nonelastic system of drive letters for addressing. The file system is here independent of the hardware. The hardware (disks, floppies, cdroms, ram, ...) cant be mounted via mountpoints in the file system.

ReactOS have to use the odd system of disk drive letters to be compatible with Windows, OS2 and DOS. :cry:

But I think it is possible to use moint point too. DOS have the JOIN-command for this:

Windows XP have the GUI diskmgmt.msc for this. I don't no if XP have a command line tool like the Unix "mount" (I don't use Windows normally).

Will ReactOS have the capability for using moint point?

Is it possible to use this capability in the start process like the /etc/fstab in Unix?


thanks
alexsunny
Last edited by alexsunny123 on Fri Feb 05, 2021 11:42 am, edited 1 time in total.
User avatar
EmuandCo
Developer
Posts: 4461
Joined: Sun Nov 28, 2004 7:52 pm
Location: Germany, Bavaria, Steinfeld
Contact:

Re: Disk Drives vs. Mount Points ?.

Post by EmuandCo »

Whatever Windows allows to do is possible in ROS either. If not then we have a bug or missing function. Windows does not use any drive letters internally. There you find names like: multi(0)disk(0)rdisk(0)partition(1).
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes
hbelusca
Developer
Posts: 1196
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Disk Drives vs. Mount Points ?.

Post by hbelusca »

alexsunny123 wrote: Mon Jan 18, 2021 10:34 am Unix-versions (Solaris, Linux, BSD, BeOS, MacOS X, NextStep, ...) don't have this nonelastic system of drive letters for addressing. The file system is here independent of the hardware. The hardware (disks, floppies, cdroms, ram, ...) cant be mounted via mountpoints in the file system.
Otherwise you can use NT device paths, for example: \??\Device\HarddiskVolumeN (with N a number) and you get the same system as *nix systems too.
User avatar
irony
Posts: 31
Joined: Tue Dec 04, 2018 4:17 pm

Re: Disk Drives vs. Mount Points ?.

Post by irony »

Windows-versions inherit the odd system of disk drive letters from the old CP/M

Unix-versions (Solaris, Linux, BSD, BeOS, MacOS X, NextStep, ...) don't have this nonelastic system of drive letters for addressing. The file system is here independent of the hardware. The hardware (disks, floppies, cdroms, ram, ...) cant be mounted via mountpoints in the file system.
why you are pushing your preference as some indisputable truth? that system with using say "forest" of FS hierarchy trees with each own root, marked with the letter, instead of just one is not "odd". not for everybody. for example I like it way more, than the nuxi approach. and oppositely, I do dislike the nuxi one tree approach. I want to see my storage volumes clearly, and "lettering" drives allow me this. whereas dissecting unix one tree with something like mount -l just spits tons of garbage in the face. forest of trees is more convenient to use for an interactive user, that is for a human.
don't have this nonelastic system of drive letters for addressing. The file system is here independent of the hardware
seriously, how drive letters are "non-elastic" and "hardware dependent"? the only difference, that unix glues all the volumes together in one tree for a user, whereas Windows represents every volume as it is - a standalone tree, so you have a forest of trees. if you are more used to the unix variant, that is ok, but it doesn't make it more "elastic" and "hardware independent", whatever you meant by that.

questions like "why reactos/windows is not like unix" are nonsense. statistically all variants of forum questions may exist, so you ask nonsense, other one asks good questions, that are helpful for them or others, the third is just a spammer. the same is with OS approaches - Windows uses a cool approach for reopresenting storage to the user, unix clones use a sucky one.

will ReactOS support the sucky unix approach? you got the answer - ReactOS aims to be very compatible with Windows, so if there some decides to put this into Windows, then eventually it will be available in ReactOS. but maybe you are better off to keep using your NextStep if you love it so much?
Otherwise you can use NT device paths, for example: \??\Device\HarddiskVolumeN (with N a number) and you get the same system as *nix systems too.
I suspect, then they will be dissatisfied with using backslash. because unix cannot use both as a delimiter. doh. maybe slash is more elastic? :lol:
MadWolf
Posts: 577
Joined: Sat Dec 31, 2005 4:19 am
Contact:

Re: Disk Drives vs. Mount Points ?.

Post by MadWolf »

a better question will ReactOS support more than 26 drives/partitions in windows you can use NTFS volume mount point
karlexceed
Posts: 527
Joined: Thu Jan 10, 2013 6:17 pm
Contact:

Re: Disk Drives vs. Mount Points ?.

Post by karlexceed »

ROS had better support Volume Mount Points:
Volume Mount Points are supported from NTFS 3.0, which was introduced with Windows 2000.
hbelusca
Developer
Posts: 1196
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: Disk Drives vs. Mount Points ?.

Post by hbelusca »

The NTFS support for volume mount points, is that it allows you to create these symbolic "directory" links within a NTFS volume, to some other volume.
But even without NTFS you can still have volume mount points, managed by the mount manager, that appear in the NT namespace as \??\Volume{SOME-GUID-HERE} . Then you can always create a symlink to these with a more user-friendly name and access that as a volume.
So again, that *nix-like functionality is already present in NT, and in a more general way.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Bing [Bot] and 2 guests