[openbeosstorage] Re: BDiskSystem::Supports*()/Validate*()
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 24 Jul 2003 15:07:14 +0200 CEST
On Thu, 24 Jul 2003 04:37:52 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > Anyway, I've been mulling over the question whether e.g. the pieces
> > of
> > information the BDiskSystem::SupportsResizing[Child]() methods
> > return
> > are actually useful for the API user. And I came to the conclusion,
> > that they are indeed. E.g. if you have a primary or logical intel
> > partition -- for which resizing will be implemented in the not so
> > distant future -- being formatted with BFS -- which doesn't support
> > resizing -- DriveSetup should nevertheless offer you the option to
> > resize the partition. Warning you, of course, that it will destroy
> > the
> > data on the partition.
>
> If you enlarge an existing partition, BFS won't even notice it (it
> will
> still operate properly but ignore the extra space).
The problem is, that we can't handle that in a consistent way, i.e.
shrinking the size will indeed corrupt the data. And when enlarging
first and shrinking then, we can't know and have to assume, that the
data are lost.
And I also wouldn't like to have e.g. a 1 GB FS residing on a 2 GB
partition without being able to get that info. What we could do, is to
add a BPartition::ContentSize(). Then DriveSetup can give the user a
very good picture of the situation. Thoughts?
> > So BPartition::Resize() needs something like a `bool force'
> > parameter,
> > indicating, that it shall not fail, when resizing the content
> > fails;
> > or
> > maybe better `bool resizeContents' specifying whether or not to
> > resize
> > the contents. At any rate that would make the semantics of
> > CanResize()
> > a bit confusing, I think (since it will just return false, although
> > calling Resize() is possible). Another parameter might be useful:
> >
> > bool CanResize(bool *canResizeContents, bool *whileMounted =
> > NULL);
>
> I am not sure if I like that way of method calling, even if I might
> be
> a bit late :)
> I think it's strange that a CanResize() call needs and changes
> boolean
> values.
At least for all operations applicable on file systems the respective
Can*() methods takes a `whileMounted' parameter. Not required, but
optional. I think `canResizeContents' is not optional only for the
reason, that I can hardly imagine, why one would not be interested in
that info.
> I would understand a:
> enum resize_capabilities {
> B_CAN_RESIZE_ITSELF = 1,
> B_CAN_RESIZE_CONTENTS = 2,
> B_RESIZE_WHILE_MOUNTED = 4
> };
> and:
> bool CanResize();
> resize_capabilities ResizeCapabilities();
>
> better (or something to that extend). The functionality itself looks
> good, though :)
In fact, CanResize() wouldn't be needed at all, since all information
would be provided by the second method. It is even less clear, what it
would return here -- whether the partition can be resized, or it's
contents, or both?
> > bool CanMove(bool *canMoveContents, bool *whileMounted = NULL);
>
> same as above.
Now the method looks even as scary as this:
bool CanMove(BObjectList<BPartition> *unmovableDescendants,
BObjectList<BPartition>
*movableOnlyIfUnmounted)
const;
So you would think of a `bool CanMove() const' and a second method
(status_t GetMovingProperies(...)).
Looks OK in principle. I'm a bit undecided though. Tyler?
> (just my opinion)
Very much appreciated. As always. :-)
CU, Ingo
Other related posts:
