Are drive letters bad?
Moderator: Moderator Team
Are drive letters bad?
Do any of you think using drive letters for mounts are bad, because you can't more than 26 drives at a time? The UNIX/Linux based systems don't have this problem, don't they?
sure its an issue, but how many people use 26 drives ? even with mapped network drives 26 is excessive..
it would be nice if there was a possible way to work around thing, but i dont see it as being a problem for 99.9999% of all people.
also *nix based systems dont have such a limit as i understand, you just mount devices to an empty folder. they do however (like any pc) have a device limit (this doesnt inclued network drives obviously).
it would be nice if there was a possible way to work around thing, but i dont see it as being a problem for 99.9999% of all people.
also *nix based systems dont have such a limit as i understand, you just mount devices to an empty folder. they do however (like any pc) have a device limit (this doesnt inclued network drives obviously).
drive letters and mount points in Windows 2000+
Since NT 3.1, drive letters are symbolic links in the kernel name space, not real device names, like in VMS and in DOS.
Since Windows 2000 you can mount physical and logical NTFS volumes to directories. They are named "junctions".
Since Windows 2000 you can mount physical and logical NTFS volumes to directories. They are named "junctions".
Re: drive letters and mount points in Windows 2000+
If you use the FAT/FAT32 filesystem, you won't be able to.ea wrote:Since Windows 2000 you can mount physical and logical NTFS volumes to directories. They are named "junctions".
I do If I mount all my (in widows mountable) partitions with a drive letter and then attach some usb-sticks (2 or 3) I run out of lettersScoTTie wrote:sure its an issue, but how many people use 26 drives ?
And mounting in directories on NTFS-partitions isn't an option for me, since I can't delete directories on the in-dir-mounted partition (don't know why there`s always an error).
I think ReactOS can do it better! But it's not so important now I think. And drive-letters are REQUIRED, since just every wndows apps require them, so there's no other way out...
This problem is fixed And I do mean Fixed.
Linux/Unix/Freebsd mount style will be supported. Ie drive inside drive. 1 drive letter might have 20 different drives inside.
This was decided in a older forum chat about it.
This was decided in a older forum chat about it.
The linux style support does not have a problem.
c:\ is one drive
c:\somefolder is another drive
d:\ is a drive
d:\somefolder1 is another drive.
d:\somefolder2 is another drive
Ie all flash drives could be place in side one drive Unless there is some partical reason why its requred to be placed else where.
Windows program still thinks its going to its old drive.
Now this could get really sneeky for network drives.
1 drive for home accound. 1 drive for all file shares.
If programs are not placing anything into windows directory.
There is no reason why programs could not be mounted into c:\Program Files\ From file shares.
Forget thinking of 26 drives think of 26 starting points that any number of drives can be stacked on.
From the program point of view Nil has changed. Only problem is the limit on lenth of filenames if windows has any.
Really only stuff like Cdrom drives cannot be stacked. Windows by default support a weak form of stacking. Ie map a directory to a drive as long as drive has letter. So all reactos lets is map a drive to a directory without giving the drive a letter. So it sould be support no problems by all programs.
c:\somefolder is another drive
d:\ is a drive
d:\somefolder1 is another drive.
d:\somefolder2 is another drive
Ie all flash drives could be place in side one drive Unless there is some partical reason why its requred to be placed else where.
Windows program still thinks its going to its old drive.
Now this could get really sneeky for network drives.
1 drive for home accound. 1 drive for all file shares.
If programs are not placing anything into windows directory.
There is no reason why programs could not be mounted into c:\Program Files\ From file shares.
Forget thinking of 26 drives think of 26 starting points that any number of drives can be stacked on.
From the program point of view Nil has changed. Only problem is the limit on lenth of filenames if windows has any.
Really only stuff like Cdrom drives cannot be stacked. Windows by default support a weak form of stacking. Ie map a directory to a drive as long as drive has letter. So all reactos lets is map a drive to a directory without giving the drive a letter. So it sould be support no problems by all programs.
This plan is not set in stone.
There are options around problems.
Virtual directory defining file. Ie a lnk like file that says enter this directory you now change to this drive.
I did not say it would not cause some that still would have to be worked around. Due to the poor limits of windows.
UNIX and Windows use different mounting methords. True. External Drives take alot more overhead to access than internal one False. Network drives can take less than internal. It all come down to the work required to interface microsoft network file access is not good for speed.
Virtual folders are used in Linux and Unix and cause verry minor over head even on Linux.
c:\data\virtual
This would be processed
as c:\data now open virtual hmm that is a vitual folder lets access the open drive and display this.
Do a subst z: c:\somedirectory then include z: in the environmental path.
You will notice only a minor speed loss. Note this is worse than mounting the other way.
Let be blunt Microsoft really does not have a Mounting Methord.
Theres is lets be lazzy and create a new drive letter each time we get a new partition in the mix.
Where Unix says we have a new partition you get to choose where you place it. Of course there is a price but its not large.
Virtual directory defining file. Ie a lnk like file that says enter this directory you now change to this drive.
I did not say it would not cause some that still would have to be worked around. Due to the poor limits of windows.
UNIX and Windows use different mounting methords. True. External Drives take alot more overhead to access than internal one False. Network drives can take less than internal. It all come down to the work required to interface microsoft network file access is not good for speed.
Virtual folders are used in Linux and Unix and cause verry minor over head even on Linux.
c:\data\virtual
This would be processed
as c:\data now open virtual hmm that is a vitual folder lets access the open drive and display this.
Do a subst z: c:\somedirectory then include z: in the environmental path.
You will notice only a minor speed loss. Note this is worse than mounting the other way.
Let be blunt Microsoft really does not have a Mounting Methord.
Theres is lets be lazzy and create a new drive letter each time we get a new partition in the mix.
Where Unix says we have a new partition you get to choose where you place it. Of course there is a price but its not large.
-
- Posts: 107
- Joined: Fri Nov 26, 2004 10:12 pm
- Location: España (perdido en el atlantico)
Add the ability to mount a volume as a folder, but retain the ablity to use drive letters, since most applications would need it. Having drive letters and directory mounts is even better than UNIX/Linux.Lucio Diaz wrote:Leave drive leters where they are, thats my vote. At least in windows I know wich HD i am working
Who is online
Users browsing this forum: Ahrefs [Bot], DotBot [Crawler], Google [Bot] and 39 guests