Re: Re: ntfs resize and gtk frontends
On Thu, Jan 22, 2004 at 04:18:10PM +0100, Szakacsits Szabolcs wrote:
>
> On Thu, 22 Jan 2004, Sven Luther wrote:
> > On Wed, Jan 21, 2004 at 10:43:33PM +0100, Szakacsits Szabolcs wrote:
> > > It isn't only about just moving the code to libntfs (I answered this some
> > > month ago on bug-parted) but
> >
> > Yep, but it is the necessary step to have do the libparted side of
> > things.
>
> Sure but also what interface libparted needs? We don't have the time to do
> it twice and checking it out isn't the highest priority now (for me).
Well, you could use the libparted filesystem handling as interface.
struct _PedFileSystemOps {
PedGeometry* (*probe) (PedGeometry* geom);
int (*clobber) (PedGeometry* geom);
PedFileSystem* (*open) (PedGeometry* geom);
PedFileSystem* (*create) (PedGeometry* geom, PedTimer* timer);
int (*close) (PedFileSystem* fs);
int (*check) (PedFileSystem* fs, PedTimer* timer);
PedFileSystem* (*copy) (const PedFileSystem* fs, PedGeometry* geom,
PedTimer* timer);
int (*resize) (PedFileSystem* fs, PedGeometry* geom, PedTimer* timer);
PedConstraint* (*get_create_constraint) (const PedDevice* dev);
PedConstraint* (*get_resize_constraint) (const PedFileSystem* fs);
PedConstraint* (*get_copy_constraint) (const PedFileSystem* fs,
const PedDevice* dev);
};
Look at the include/parted directory in the parted source for everything
you need.
> In high level, resize could tell the constrains and do the resize but
> for example, it's quite probably in some cases it needs to remount
> the partition 3 times. Can [lib]parted live with that?
I know nothing about ntfs, but i suppose it is somewhat silly to have to
mount the partition while resizing it.
> > I am interested by your opinion, what is it in parted that you dislike
> > and why ?
>
> Mostly my lack of knowledge about its internals :) But seriously,
>
> - one of the most disliked one described below, even a patch is provided
> to solve it (at least partly),
>
> http://mail.gnu.org/archive/html/bug-parted/2003-05/msg00046.html
>
> Knowing where things are in sector level is very important
> occasionally.
Notice that this is a critic of the parted program, it doesn't apply to
the underlying libparted, which is what matters. Libparted uses
geometries which are of the start/end/size kind of information, where
all three of those are 64bit integers.
> - decimal point usage in sizes is IMHO confusing, useless, ridiculous
> (partition size is e.g. 315003089.536 bytes). If one needs better
> resolution then he/she should use smaller units. But see above.
Mmm, i don't know about this.
> - no save/restore partition table functionality. Partitioning is very
> messy, complicated, a lot of scenarios. When somethings goes wrong
> (quite frequently if you read/filter many lists/etc) the only you can
> say "sorry, maybe next time" (or try testdisk, gpart, etc -- I hear
> better results than using parted's 'rescue').
Ok, i agree with this, but it could easily be implemented.
That said, only the parted programs commits after each change, it is
perfectly possible to have a libparted using program which does all the
changes in the in-mem copy of the partition table, and do everything at
once once you are happy with it. Doing filesystem creation is the
problematic part, but i guess even that could be queued.
> - offered choice 'ignore' to the users when it is _nonsense_ and would
> destroy their data. It does as it were demonstrated several times.
Again, a parted interface problem, not really related to libparted. This
could easily be done in any graphical tool using libparted or something.
> - "report this .... bug" instead of "check out ... for updates, etc"
> Unfortunately there isn't any Changelog/FAQ on the Parted site, not to
> mention link to the latest release.
This is a real problem, but again not one of libparted per see, more one
linked to the fact that there is no open CVS or whatever repository.
This has to be solved soon, or parted will be forked or something.
> > I personaly am a bit disapointed by the code quality of
> > parted/libparted,
>
> Would you mind to express?
Just a general impression, and the lack of accessible CVS repository
doesn't help. The parted UI often dies for no reason at all, there are
some garbage asserts in there which are leftover and makes thing fail
horribly in some cases, and so on. I think the main problem is that
there is need of more active maintaining and some cleanup of the
internal stuff.
> > and have been toying in doing a reimplmentation in ocaml, with maybe
> > some coq-based prooves of good behavior, and having coq generate the
> > corresponding code afterward. But i lack some time for this, and am
> > not sure an ocaml-based libparted reimplementation would be welcome.
>
> I'm afraid it wouldn't be :)
>
> - most distros ship parted but I don't know any who ships ocaml
most ship it, debian ships (and i am the maintainer of it) it. Lindows
even use it for hardware detection and such in their installer.
> - many people know C thus they might contribute but most doesn't
> know ocaml and should learn it to do so
Yeah, sure.
> - you would throw away a lot of "hidden" knowledge in parted and
> you should rediscover them the hard way
Well, i already did part of that for implementing amiga partitioning
table and filesystems.
But then, you forgot the good sides, namely that a pure ocaml program
cannot have runtime kind of errors, and that by doing a coq proof and
and automated code generation from the proof for the critical pieces of
the software, you would have a tool which was proven correct, which for
partitioning handling would be a nice thing to have.
Also, ocaml often means a tenfold reduction in code size for the same
thing, which makes maintenance easier, and the fact that ocaml has
functions as first class values, would make what libparted does much
much easier.
The objection i would have, would be more that you would have to bind in
the ocaml runtime and virtual machine, which may be problematic in the
small size initrd case of installers, and the fact that dynamic linking,
altough possible, is not all that easy.
> > BTW, the main problem of parted/libparted right now, is that there is no
> > CVS repository of it, and that the code has been mostly unavailable
> > since may 2003 or so.
>
> Yes and somebody who has the time to maintain it.
In the worst case, we can always start an alioth project.
Friendly,
Sven Luther
Reply to: