DOS VS Unix drive accessing

[ucosty]

Essentially, though, what you are saying Brynet is that you basically use trial and error to find the right partition on the right device. Without using the ID based mounting system (in linux, don't know about others) you can't even guarantee that mount points will remain the same between reboots.

A problem I had with an old CentOS box connected to a removable drive that, before we got a UPS, used to swap device positions with one of the internal drives for no apparent reason. That was really annoying.

[Brynet-Inc]

Essentially, though, what you are saying Brynet is that you basically use trial and error to find the right partition on the right device.

Not at all, I simply meant it's up to the user to maintain their own "mental" inventory of the devices in their computer.

If I plug in an external USB hard drive, I'm going to know the kernel will assign it as an "sd" device, it's safe for me to assume sd0 because I have no other SCSI devices on the system.

As for guessing partitions, not at all... the fdisk and disklabel utilities help me determine the partition I'm looking for, the actual device nodes representing each (BSD-style) partition are easy.

sd0a through p, "c" representing the entire device, "i" and "j" representing other foreign MBR-partitions, an MSDOS/FAT32 one for instance.

I could of had "tail -n 0 -f /var/log/messages" running in a terminal while I plugged in the USB device.. eliminating most, if not all, of the "trial and error" elements.

I believe users should be in control of their systems, being aware of how your devices are handled by the system... should be a requirement.

[binutils]

JamesM, seriously your hit-and-run posting is getting a little annoying.

[JamesM]

JamesM, seriously your hit-and-run posting is getting a little annoying.

I didn't post any links, genius. Get your definitions right next time.

[binutils]

Okay :)

[AlfaOmega08]

I believe the user should know the drive he's working on.
This is the main reason to use a windows-like style.

For the usb disk question, yeah, it's right. You don't know which is the right letter. I've found, in my opinion, the best solution to this problem on Ubuntu. In Resources->Computer, if you have a card reader, you have "Memory Stick Unit", "SD/MMC Unit" (I don't know if these are the right translation...) and things like that.

On Windows you have another trouble... Once you end the 26 letters, wath would happend? I never tried...

Some people here says that you can mount a drive on /home to have your home directory on that hd. On Windows you have just to change the label and change the directories address (it's a bit long, but...)

When I've used linux for the first time, the thing I've immediately hated is mount and unmount. Why should unmount a drive? Just to not use it until the end of the session (I'm talking from an user point of view).

I know also windows unmounts drives. But just when you remove them. In any other situation it's completely free from the mount command

[JamesM]

Hi,

On Windows you have just to change the label and change the directories address (it's a bit long, but...)

This is the thing that kills transparency, and makes moving directories hard. On a *nix system there is no need to change the directory's address, so all scripts work as per normal.

Cheers,

James

[nekros]

JamesM, seriously your hit-and-run posting is getting a little annoying.

I don't know you very well binutils, but I am seriously starting to doubt your intelligence. How in hell could any of his posts be hit and run. Is this just a plot of yours to point out someone instead of yourself, because all you ever to is hit and run posting.

[binutils]

JamesM, is that you?

--
PS: don't get seriously, just j/k.

[robos]

I like how on OS X a drive shows up on the desktop when you plug it in. I dislike that it's mixed in with the other icons you have on the desktop.

So I think I'm leaning towards the hybrid approach where you have a single tree where everything is available but you can also single objects out.

[bewing]

I agree with many of you. Drive letters (specifically) are astonishingly primitive, and limited. We are not talking here about DOS/Windows vs. flavors of UNIX. We are all creating our own OSes, and the questions are: which method should WE use (or a hybrid mixture)? Which methods are the hardest to code? Which methods are the most complex from the OS' point of view (along with the user's POV, of course)?. Which methods are slowest and add the most overhead?

I think that one of the most telling points is how difficult it is to get the current free space off a *NIX tree-style FS. I am an application. I want to store a file that is X MB, in directory /home/me/foo/bar. Is there enough space? Aaaaargh! I don't know! I don't even know which mounted partition that is! It's too transparent.

As said above (indirectly) what you want in your OS, is a method where the "volume name" (in whatever form) that you use to refer to a particular storage partition remains constant forever. Mostly, this means that you want to refer to every volume/partition that you mount into your VFS by a name -- rather than by a meaningless letter, or a nearly meaningless reusable directory mountpoint.

Now, it is also true that drive letters are short and sweet and pass the KISS test. Directory mountpoints are very transparent. Many posters have pointed out the advantages of having both implemented in an OS. Maybe implement all 3! Drive letters, directory mountpoints, and access by volume name. With an API that will let you conveniently convert between each style. Overall, I agree with jal, certainly. A proper OS will abstract all of this in the most convenient possible way for the purposes of the OS / user / application / developer. But the devil is in the details. I think that all partitions must be forced to have distinctive (unique at runtime) "volume names". And it will probably be the CD, and not the CD-RW drive, that contains that volume name. So, swapping media will change your global VFS tree structure.

why would you care which physical partition it's on?

Because (as said above) if you have 3 flash drives attached to your system, and you want to put a file on one of them, pull the thing out of your USB port, and hand it to someone -- you'd better be certain which is which. This does not work well with mountpoints OR drive letters.

One reason that I dislike drive letters is that occasionally my system configuration changes. I move the CD drive to another system. I add a RAMdrive. And then all the drive letters of all the "downstream" drives change. Very annoying.

Not at all, I simply meant it's up to the user to maintain their own "mental" inventory of the devices in their computer.

I can't possibly go this far. My OS is not going to exclusively be for "power users". The appeal of a GUI desktop is that it makes computers usable for technophobes -- who can barely keep an inventory of the shoes in their closet, let alone the names and locations of all the currently mounted devices in their highly abstracted VFS.

[lollynoob]

I, as a user (and a "power user," on top of that even), don't care about transparency or flexibility. I've never had the need to mount a drive into another drive's filesystem, nor will I ever have more than 26 drives on one computer, so those problems aren't really problems in my case. With that out of the way, I really like the convenience of absolute locations for all of my files; so I can say "file A is on drive B which is my hard disk," not "file A is in this subdirectory of this mountpoint which is a device in this subdirectory of ...".

The fact that it's "primitive" doesn't make it any less useful.

[iammisc]

@bewing: Yes but this is entirely possible with the unix style, either mount the specific drive under somewhere descriptive yourself or let HAL do it for you. My point is: how is does a drive letter help you distinguish partitions more than your own(or HAL's) more descriptive mountpoint.

How would you remember that d: is flash drive 1 and e: is flash drive 3. On the other hand, if you gave the flash drive's names, you could mount them at /mnt/<name> or let HAL do it for you.

@robos: you brought the point up about mountvol. I already said that it is possible to do some linux stuff in windows. However, if you had read my post, I said it was more pervasive in linux(and it is, in linux, you have to mount it somewhere).

I know also windows unmounts drives. But just when you remove them. In any other situation it's completely free from the mount command

What are you talking about? If you remove a flash drive in windows, you should right click it and say eject, otherwise the operating system might not have flushed its disk caches right. Same on linux, you just use the unmount command(you could also right click and select "Unmount volume.." in a desktop environment).

When it comes to unmounting linux and windows are exactly the same: you should really unmount them, but if you just pull the drive out, none of them will scream at you(although you could lose some data in both).

I believe the user should know the drive he's working on.
This is the main reason to use a windows-like style.

That's why you mount them someplace descriptive.

Some people here says that you can mount a drive on /home to have your home directory on that hd. On Windows you have just to change the label and change the directories address (it's a bit long, but...)

If we're arguing over ease of use, then this is definitely not easy, especially something used so often as your home directory.

I can't possibly go this far. My OS is not going to exclusively be for "power users". The appeal of a GUI desktop is that it makes computers usable for technophobes -- who can barely keep an inventory of the shoes in their closet, let alone the names and locations of all the currently mounted devices in their highly abstracted VFS.

Well if you go the windows route, they're going to have to remember which cryptic drive letter got assigned to it...

[inx]

Personally, I've thought about implementing a hybrid Unix/Amiga-style system, with drives accessible via device name ("df0:" for first floppy drive, "dh0:" for first hard drive, etc), volume name ("Workbench:" for any drive labelled workbench), and just the usual Unix tree. Really, though, what's the point?

For volume names, the BeOS/OSX way works fine (/<volname> or /Volumes/<volname>), for device names, you can just mount them like we've been doing forever in Unix, and for the Unix tree, that can fit in any way you'd like.

I always come back to the Unix tree, though, because bits of the OS being tethered at install-time to a certain volume name or drive letter is just not transparent enough, and the access-by-volume-name can easily just be implemented with mountpoints on a RamFS.

My point is, all other abstractions can be worked in under a Unix VFS, and peacefully coexist, at that. However, the Unix VFS does not work in very directly under the other abstractions (Cygwin is unbearable to me due to its lack of root directory integration with the rest of the system. But Windows doesn't really have a user-accessible root directory to integrate with.) So, personally, I'll be sticking with what seems the most flexible to me.

[AdHawk]

UNIX doesn't solve this... /media/usb0 is a USB drive to be sure... but which one? The best solution to that problem, IMHO, is to put the drive label in the filename: /media/jack-usb or jack-usb:/ etc

Most Linux Distros i've used recently, k/Ubuntu, Fedora8, Slackware, etc. do exactly what you're saying. it just goes under media:<drive lable> I believe this is because of the HAL they use. Now on some systems it's not properly mounted at this point, but you can easily mount it using that /media:<drive lable>

If you're used to the M$ way of doing things you'll wonder why anyone would do it the UNIX way. But if you use enough UNIX you'll quickly grow used to it, and possibly even prefer it.

For example, properly unmounting a drive on Vista can be hell. If you have an explorer open to a location on the drive it wont let you unmount. If you have an application open(say winamp) which holds links to a couple locations on disk, it usually wont let you unmount. On Linux, and other UNIX variants, umount -f will (in most cases) unmount the drive cleanly and just terminate the links to the programs using it, which is a lot easier for me since i load the taskbar with tons of apps making it hard to find which one i would need to close.