OSDev.org

robos wrote:bewing: funny, I don't consider any design decision to be a minor one, but that might be me One thing I have learned is what looks to be a small insignificant design decision in the end might turn out to be a major one. Especially things that have to do with security and user interaction with the system.

Read4Dis: I'm wondering what you're going to do when a user attaches two drives / discs with the same volume name... any thoughts on that?

Well, in that case I would append a # onto it, the user will then be able to change the names so they don't collide. I'm still not 100% settled on this method, but it's as good as any other I found in use.

I am using volume names, too, as my main access method. You tell the user that the volume name of the drive they just mounted is an impermissible duplicate of a currently mounted drive, and you insist they enter an alternate, temporary name for the new volume.

The Unix name space is more flexible. In fact, it's flexible enough to actually allow for almost full emulation of the Windows name space. For example, you could just mount everything at the root and give them names like c, d, e, then it's up to the application to display Windows-like paths. If my example is bad, just take a look at how Wine builds it's Windows-like name space on top of the Unix name space. Sorry if this was said before, but this thread is mighty long to read entirely.

zaleschiemilgabriel wrote:The Unix name space is more flexible. In fact, it's flexible enough to actually allow for almost full emulation of the Windows name space. For example, you could just mount everything at the root and give them names like c, d, e, then it's up to the application to display Windows-like paths. If my example is bad, just take a look at how Wine builds it's Windows-like name space on top of the Unix name space. Sorry if this was said before, but this thread is mighty long to read entirely.

Yeah, like I mentioned, internally both are handled similar, it's just how they are presented to the user that is different. There is no reason why you can't just display the disk name rather than the drive lietter in windows explorer, and windows supports linking of disks to directories, so it can look just like linux as well. It's just an interface, but could make a difference about what type of API is required to find the devices (Specific block device list, or a more generic VFS directory scanning). Either way, you can display it how you want to the end user.

Unix is old

Gavin wrote:Unix is old

And you are young...

Gavin wrote: Unix is old

So is the idea of having cooked food, but you're not going to scrap that are you?

Don't confuse an operating system with an application.

Gavin wrote:Don't confuse an operating system with an application.

Where exactly are people here getting confused on that point? [citation needed]

JamesM wrote:

Gavin wrote:Don't confuse an operating system with an application.

Where exactly are people here getting confused on that point? [citation needed]

maybe people confuse the internal work of the VFS with the user interface for filesystem?

I prefer the old Mac OS way: Every filesystem has a name.
But with some extensions.

If your harddisk has the name "Jims PC", then file + fullpath is accessed by "Jims PC:/System/kernel".

Every name can have an alias.
For example $boot is the bootdisk, so "$boot:/System/kernel".
Or ata0 disk0 part1, "$ata0d0p1:/users/peter/photo.jpg".

$system points not to a real filesystem, but to the system-directory, so "$system/kernel" access "$boot/System/kernel".

I am generally a Unix fan, but here's my perspective on this:

The Unix style of arbitrary mount points on a single tree hierarchy is great for a system where the intention is to hide the physical implementation of the system from the user. For instance, maybe the home directories are mounted via NFS from another host, while the root filesystem is on some robust storage and the bulk of the data is spread out over a couple of other drives. For this kind of thing, it makes absolutely no sense to have each of those volumes be a separate "drive" at the UI level. Beyond that, I think with today's systems it makes all kinds of sense to have the core of the system be at something that is unambiguously the "root". Windows inherited DOS style, which in turn evolved from a floppy-based system to a hard drive system - with the consequence that the original "system root" of A:\ turned into C:\ as floppy drives became less frequently used as the boot device... So I think that's generally quite nice.

Where the Unix approach doesn't work so well is on removable media - floppy drives, USB devices, etc. - where the normal usage pattern is to plug 'em in, use 'em, then pull 'em and use 'em somewhere else. Fitting such ephemeral filesystems into the main hierarchy doesn't really make a lot of sense - it's kind of a compromise IMO, but one that can be made to work reasonably well with the right naming strategy. Ideally I think removable media should be more clearly in its own space - but I'm not so determined on that point that I would necessarily set aside the required syntax to make it happen...

Drive letters in this case aren't a fantastic solution either (Is my USB stick E:? F:? G:? I never know, it depends on what's already set aside... At least the GUI can help me in this case) but I believe Windows has alternatives to this as well... The volume-name-based strategies used on various OSes these days work pretty well I think.