PK>> Then the "issue" over the visibility and ordering of
 PK>> primary/logical partitions goes away completely...

 JdBP>> Actually, no it doesn't go away.  It is just renamed in the hope
 JdBP>> that  everyone will overlook it. (Amazingly, this actually seems 
 JdBP>> to happen.  (-:)  What on "PC style" operating systems is an issue 
 JdBP>> of drive letter assignment order is, on PC unices, an issue of the
 JdBP>> assignment order of device numbers.  One still has to change things. 

 PK> Try as I might, I can't see your logic here. 

The fundamental problem being addressed, which I don't want to lose sight of,
is that when one creates or deletes partitions the assignment of drive letters 
changes.  The scheme that you have suggested doesn't actually fix this
problem, it simply renames it.  Instead of having problems where E: becomes
D:, F: becomes E:, and so forth, the user has problems where the "mount table" 
for the system (which, as you described, contains entries that map a
{disc,partition} pair to a subdirectory) suddenly references completely the
wrong partitions, and large chunks of the file hierarchy suddenly start
playing musical chairs.  Essentially this is the *same problem* as the user
had before, just in a different guise.

Yes, the user can go and edit the mount table.  But that, too, is a
disadvantage in a way, compared to the way things are now.  The mount table is 
supplied by the user.  If the user modifies the partition table in any way,
he/she *also* has to add, delete, and renumber all of the entries in the mount 
table to mirror the change.  Compare this to the current scheme where at least 
if one creates a partition one doesn't have to do *further* work to have a
drive letter assigned to it.  When one creates a partition with the scheme
that you describe, however, one has to manually renumber the entries in the
table, because the creation of the partition has shifted the numbers along. 
And one *also* has to manually add a new entry for the new partition.

Worse, there's no way to automate this process.  Consider the case where one
has two operating systems, on separate partitions, that one wants to keep
entirely separate from one another.  With the drive letter assignment scheme
that operating systems employ today, if one alters the partition table to
create a partition *both* operating systems will create a new drive letter for 
it automatically without any further intervention.  There's no need for one
operating system to "tell" the other about the change.  With the "mount table" 
scheme, however, the partition creation utility has to update both mount
tables, lest they become out of synchronisation with the actual partition
table.  But it cannot do so because (a) it doesn't necessarily know of the
existence or location of any but the mount table of the operating system that
is currently running, and (b) it may have no way to access the mount table of
other operating systems even if it did know that they existed and where they
were (The operating systems are deliberately being kept isolated from each
other, remember.  The other operating system's partition may not have been
mounted at all.).

Doing away with drive letters and replacing them with a mount table does not,
in fact, fix the problem that requires fixing, which is minimising the impact
of changing the partition table on system configuration.  It simply renames it 
in the hope that it is overlooked.

Does that make it clearer ?

 ¯ JdeBP ®

--- FleetStreet 1.22 NR
138/2
397/1