Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote: > > > > > If > > > > that > > > > would require absolute blocks, we should go back to the drawing > > > > board > > > > :) > > > > > > If UDF does, I would vote for omitting support for it out of > > > principle > > > (if necessary, locking Tyler into some basement without > > > computers). > > > ;-) > > > > :-P That's a really bad idea all around. :-) > > > > Seriously, with no UDF support, you have no DVD support. And > > iso9660 > > is > > no better, and we sure aren't dropping CD support. How about > > BDiskSystem::UsesAbsoluteAddressing()=3F > > Let me clarify this a bit (I was in a bit of a hurry last night... > :-/). We could support generic moving for any disk system that didn't > require absolute addressing. For those that do, they can either > support > moving themselves, or just be immobile (which, as Axel pointed out > earlier, won't matter in most cases anyway since they'll usually be > on > optical media anyway). Agreed. > > > > > > class BDiskSystem { > > > > > > public: > > > > > > bool SupportsParentSystem(const char *system) const; > > > > > > // True in most cases. NULL =3D3D3D=3D3D3D raw device. > > > > > > bool SupportsChildSystem(const char *system) const; > > > > > > // False for most file systems, true for most > > > > > > partitioning > > > > > > // systems. > > > > > > > > > > > > bool IsPartitioningSystem() const; > > > > > > bool IsFileSystem() const; > > > > > > }; > > > > > As said above, I would make them virtual. Moreover, the > > > > > Supports* > > > > > System() > > > > > should also have a BPartition* parameter. Otherwise > > > > > partitioning > > > > > systems > > > > > that allow only a limited number of levels can't give an > > > > > authoritative > > > > > answer here. The BPartition* parameter could optionally be > > > > > NULL > > > > > to > > > > > ask > > > > > whether it is supported in general. > > > > > > > > I think there should be read-only set of classes, and an > > > > additional > > > > add > > > > -on based set to actually do any changes. This will be only > > > > rarely > > > > used, so it probably doesn't make much sense to clobber the > > > > general > > > > API > > > > with it - so I like something BDiskSystem (as a virtual (and > > > > abstract) > > > > base class), but it should contain everything, and not only the > > > > check > > > > operations. > > > > Thoughts=3D3D3F > > > > > > You mean that e.g. BPartition::Move() would be ommitted in favor > > > of > > > a > > > BDiskSystem::Move(BPartition*,...)=3D3F > > > Mmh, that doesn't sound very convenient. > > > > No, I don't think I like that either. > > And to clarify a little here, having immutable classes that are > updated > via a separate interface makes it more difficult to batch complex > operations on partitions that don't exist yet (i.e. creating and > initializing a bunch of new, even nested partitions). I don't really > feel like the general API is being clobbered here, just further > augmented. That's my opinion, too. CU, Ingo