OSDev.org

Rhob wrote:

Combuster wrote:Most programmers can't deal with my mom as an end user.

Agreed, but I think that's another issue entirely.

It's not, and it obviously applies especially to you.

You can't consider practical use if you don't consider the average stupidity of the end user. Einstein may have invented relativity, but your neighbour isn't going to DIY a nuclear power plant just because Einstein was epic. He just wants to flip a switch and see something work.

Similarly, your systematic rejection of subject matter that appears irrelevant or technical qualifies you as an end user rather than a developer. I'm getting the idea I'm wasting my time on a leecher.

personally, i'll go for a CP/M, but not including an identifier for the device as part of the path, for now all filesystem related function in my kernel require to supply a file system id and a path, i find this cleaner

but the global bottom issue that none of those system really solve, is to be able to uniquely reference a storage device to be able to reference a ressource locate on it, without being dependant on os or bus specific id

on linux you'd traditionally have device referenced through an hardware mapping, as you would have hda1 , hdb1 etc, but if you switch the harddrive master/slave on the bus, the reference is lost

on window the driver letter are assigned arbitrarily so you still can't make a reference to a specific ressource on a specific filesystem on a specific hardware device

on linux with devfs i saw they made something for that you can use /dev/hard drives/something/SERIAL and can allow to identify filesystem with their serial number, or same thing can be used with volume name as most filesystem contain volume name information that can be use to identity the filesystem in the global sytem, but it could allow for conflicting name being used

there is not really any system that provide a really good solution to be able to address a ressource on a specific filesystem, i thougth something like computing a sort of hash from volume name, serial number, position on the media, type of the device, could be used to make unique id for any filesystem present, and then some sort of hash table could be used to resolve the id to a more human friendly name, but all filesystem access would use this id to reference a file on this filesystem

nothing would prevent to have a sort of 'root node' to represent all system resouce, even if it's not an actual filesystem, and to insert file system entry into it, to be able to easily access all file system as system ressource without having to use mount point on actual true filesystem, which will make the actual content of the directory used as a mount point unavaible

and i find it more logical to use ressource specific to any filesystem to represent it, rather than having it all mounted within a file system that can't even really tell easily on which drive/filesystem the actual file being accessed is, and it make fixed file path very dependant on the way device are mounted

in the ideal, i'd use a very solid way to be able to build an unique resource identifier that can allow to uniquely represent a fileystem with potentially a system as mentionned above, and then using this filesystem id and the actual path of the file to reference the ressource

this approach might have flaw as well, but it would be the way i'd go

Sorry if this has already been noted; I haven't read the whole thread. Mounting using labels doesn't entirely solve the problem since you'll be forced to number volumes with the same label---which could be mounted in any order. A less convenient but more bullet-proof solution would be to use a S/N or GUID.

Love4Boobies wrote:Sorry if this has already been noted; I haven't read the whole thread. Mounting using labels doesn't entirely solve the problem since you'll be forced to number volumes with the same label---which could be mounted in any order. A less convenient but more bullet-proof solution would be to use a S/N or GUID.

That, or you can simply disallow mounting volumes with identical names.

i thougth about a system who could write a file entry in the filesystem the first time it's mounted with an unique id identifying it, possibly based on a combination of serial/volume name/type of drive, and then this id could be used to reference the hard drive on the system, no matter on which bus it is, it could work at little scale like at home but probably not at large scale due to the need of each id to be unique, and it wouldn't work for read only filesystem, but for read only file system like iso , some crc could be made on the data, like on the table index, to identiify the drive on the system

with mount point, it can also allow the opposite functionality, if for example on a station some back up hard drive would be mounted on a particular point, the softwae wouldn't need to care which hard drive it is on to reference it's file system, only the mount point matter, but that could also be achieved by some system of alias without too much problem, and i don't think it's a common use for home computer, as each hard drive and filesystem would be unique and having it's own role of functionally, unlike on station where any hard drive or storage device could be used to store the same information with ghost copies or raid - like system


i don't know if all type of drive have serial number, or if serial number could be enought, cause an hard drive can be reformated and in that case the file system on it would not be the one corresponding to the references of file path stroed for that serial number, or sometime it can also be usefull to abstract the actual hardware, like if raid like system could be used, or ghost file system copies froma disk to another, file path should still be able to resolve to the good filesystem even if it has been copied from a drive to another, even from an harddrive to an usb stick

the best of the best would be to make a filesystem that can identify some ressource on itself, like a filesystem would work wih 'bundles' that represent either the folder of an application, or a game, or some unique id that would be used for any 'bundle' that would include all sub directories as the id, and then those bundles could be copied from a file system to another without problem, and an application could be moved from a place to another without any need for reinstallting anything, if would just make the process of file openning a bit longer , as all filesystems should be parsed to find a particular ressource, but bundles could be also stored in an index table for the filesystem, and certain number of things could be cached

in itself it would be close to the system of package on unix, except all files would be access via the name of the package they belong to, and the system would keep track of where the file of that package are located on the system, theorically it could even allow for two different version of the same application to be installed in the same time and switched to easily with aliases

one would then use concept related to package or bundles to manipulate file system instead of regular file path

on macos they use this system with bundle or framework and make an abtraction of the file system to reference a file throught it's framework or bundle, you can include a file in a program throught it's frame work name and not throught it's file path, i found this system can be usefull and nice, even if i found it more boring and annoying than anything on macos, it could be improved

halofreak1990 wrote:

Love4Boobies wrote:Sorry if this has already been noted; I haven't read the whole thread. Mounting using labels doesn't entirely solve the problem since you'll be forced to number volumes with the same label---which could be mounted in any order. A less convenient but more bullet-proof solution would be to use a S/N or GUID.

That, or you can simply disallow mounting volumes with identical names.

What problem would that constraint solve? It certainly doesn't clear up the confusion. Suppose you have two USB drives (A and B), each having a partition (labeled L). Can you tell which volume is mounted from the path /mnt/L? Obviously not, so why is this better than allowing both /mnt/L and /mnt/L~1?

I've only read the first paragraph of the next response because it seemed uninteresting. However, as an alternative, consider creating a label from a cryptographic hash function applied to the content of the partition (e.g., MD5)---that way, it's not an inconvenience to plug in two drives with identical content because you'll get the same mount path for the same content. Alas, I think that may require quite long, non-descriptive labels. And no, I didn't like my GUID proposal either.

Love4Boobies wrote:

halofreak1990 wrote:

Love4Boobies wrote:Sorry if this has already been noted; I haven't read the whole thread. Mounting using labels doesn't entirely solve the problem since you'll be forced to number volumes with the same label---which could be mounted in any order. A less convenient but more bullet-proof solution would be to use a S/N or GUID.

That, or you can simply disallow mounting volumes with identical names.

What problem would that constraint solve? It certainly doesn't clear up the confusion. Suppose you have two USB drives (A and B), each having a partition (labeled L). Can you tell which volume is mounted from the path /mnt/L? Obviously not, so why is this better than allowing both /mnt/L and /mnt/L~1?

I've only read the first paragraph of the next response because it seemed uninteresting. However, as an alternative, consider creating a label from a cryptographic hash function applied to the content of the partition (e.g., MD5)---that way, it's not an inconvenience to plug in two drives with identical content because you'll get the same mount path for the same content. Alas, I think that may require quite long, non-descriptive labels. And no, I didn't like my GUID proposal either.

sometime the behavior required could be also to have a same mount path for different content, in case of back up drive being plugged in specific slot and mounted at a specific place no matter the filesystem on it

So, a few years have passed and I've gotten into OS development again. But first...

Combuster wrote:It's not, and it obviously applies especially to you.

Perhaps you'd like to explain what you mean here, Combuster.

Combuster wrote:You can't consider practical use if you don't consider the average stupidity of the end user. Einstein may have invented relativity, but your neighbour isn't going to DIY a nuclear power plant just because Einstein was epic. He just wants to flip a switch and see something work.

Similarly, your systematic rejection [sic] of subject matter that appears irrelevant or technical qualifies you as an end user rather than a developer. I'm getting the idea I'm wasting my time on a leecher.

For one thing, I'd love for you to explain just where I've systematically rejected anything. For another, I'd really love for you to explain just what you mean by "leecher". Thanks in advance.