[openbeosstorage] Re: My Usual Confusion

On 2003-06-19 at 03:13:59 [-0700], Ingo Weinhold wrote:
> On Thu, 19 Jun 2003, Tyler Dauwalder wrote:
> 
> [...]
> > > 2) Why not introduce a BPartition::SetType(), that tells the
> > > partitioning system to set the type of the partition? Or maybe 
> > > rather
> > > add a boolean parameter to Initialize() indicating whether to 
> > > only set
> > > the partition type or to also let the supplied disk system format 
> > > its
> > > contents?
> >
> > I think I like the SetType() way better. Initialize(bool) would 
> > leave
> > me feeling slightly uneasy that perhaps I got the boolean value
> > incorrect when I only wanted to change the partition type.
> 
> Though, if we aim to enforce consistency between partition type and
> partition content, setting the type should actually not be allowed.

Is this really necessary though? Certainly we should make it easy for 
matching types to be assigned, but I don't know that it needs to be 
strictly enforced to the point of disallowing the partition type to be 
changed if desired.
 
> Mmh,
> maybe introducing a SetType() (or a boolean flag for Initialize()) 
> might
> not be such a good idea. Perhaps the standard Initialize() plus a
> CreateChild() taking a partition type is fine for the userland API. 
> The
> partition module needs to offer functionality for setting the 
> partition
> type in any case, though.

I think I'd rather see that functionality left in. What if some other 
OS sets your partition type incorrectly?

> Due to getting rid of ContentType(), what can happen, if we provide a
> SetType() is, that, if you e.g. invoke SetType("FAT 32 Filesystem") 
> on a
> BFS formatted partition, the Type() will afterwards still be the same.

i.e still "BFS"? That seems okay to me. If the user does something like 
that, they very well ought to have a good reason, or they get what's 
coming to them. I just don't feel it's our place to rule out the 
possiblity they might in fact have a good reason.

> Mmh, maybe, the Type()+ContentType() approach is not that bad after 
> all?!
> Consistency between the two could still be enforced on 
> initialization, but
> we can also have a SetType() that doesn't confuse the user. IIRC the 
> only
> argument against representing both types was, that we'll often have
> reduncancy. Which I could easily live with...

Well, as long as the reason from bringing it back is simply to make 
partition type info fully accessible. I think the Type() to disk system 
module relationship should still exist and be the main method of 
determining which disk system to use for a given partition.

And how about SetPartitionType()/PartitionType() along with the current 
Type() instead of the old naming method? I'd rather the more important 
one have the shorter name, and the partition type is mostly of academic 
value. 

-Tyler

Other related posts: