[openbeosstorage] Re: BDiskSystem::Supports*()/Validate*()

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeosstorage@xxxxxxxxxxxxx
  • Date: Tue, 29 Jul 2003 01:05:45 +0200 CEST

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> On Mon, 28 Jul 2003 09:35:10 -0700 Tyler Dauwalder <
> tyler@xxxxxxxxxxxxx
> > > Do you mean all of the new suggestions or only the one for 
> > > Resize()? 
> > I believe he is just referring to enlarging a partition without 
> > enlarging its contents.

I did :-)

> > I think that's a good way of handling the described semantics, but 
> > I 
> > also think Axel has a good point: why would you want to resize a 
> > partition but not its contents?
> E.g. if you're not interested in the contents anymore (resizing the 
> contents probably takes quite some time, which is wasted, if you want 
> to ditch it anyway). Currently Resize() is implemented so that, if 
> you 
> pass false for `resizeContents', the contents is nuked. I think, the 
> start of the discussion was, that enlarging the partition wouldn't 
> destroy the contents, so that one could actually keep it.

If the partition contents shouldn't be resized (because you plan to get 
rid of them), why not just removing them before? (oh, as you write 
below, anyway ;-))

> > Having ContentSize() around in case 
> > such a thing happens due to someone else's tools is probably a good 
> > idea, but doesn't it seem more natural to always resize the 
> > contents 
> > with the partition?
> Yep, I think, it is. Maybe it's a good idea to introduce a 
> BPartition::Uninitialize(). Then, if you aren't interested in the 
> partition's contents, you would call Unitialize() before Resize(). 

Yes, I would like that better.

> Resize() wouldn't have the `resizeContents' parameter anymore, since 
> it 
> would always resize the contents. The question is, what should be 
> done, 
> if the content disk system doesn't support resizing. I guess, it 
> would 
> be consequent to just fail then.

Or have a "force" parameter. To give a somewhat dumb example, what I 
needed to do once after Windows fdisk messed up my hard drive: I needed 
to recreate the old partitions *without* destroying the contents at all 
(at least, that was the plan :-)).
But I guess that's a very special need that probably shouldn't be 
addressed by the API at all.

> BTW, Move() could work similar: The `bool force' parameter could be 
> dropped and the method would fail, if any descendant's contents could 
> not be moved. The API user would need to invoke Uninitialize() on the 
> concerned partitions before calling Move().

Or have the "force" parameter with Resize() as well :)

Adios...
   Axel.


Other related posts: