Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem
On Sat, Jul 05, 2003 at 11:57:35PM +0200, Falk Hueffner wrote:
> Ralf Treinen <treinen@club-internet.fr> writes:
> > > E2tools is a simple set of GPL'ed utilities to read, write, and
> > > manipulate files in an ext2/ext3 filesystem.
> >
> > please excuse my ignorance - what would be the advantage of these
> > tools over the core file utilities which use the VFS layer?
>
> You don't need root. Useful for example to build rescue floppy images.
Actually, you can do this with debugfs. That's how Real Men (tm)
build their initial bootstrap images. (i.e., Linus Torvalds, when he
was first bootstrapping the Alpha port.)
That being said, the e2tools does have an easier to use user interface
than debugfs, and reduces the chance that user will harm himself; sort
of like the difference between using an Exacto knife and one of those
scissors with rounded ends that gets handed out to pre-schoolers. :-)
That's not a bad thing, and certainly I'm not saying it shouldn't be
packaged. In fact, I think it's a good thing, just as like the mtools
suite is useful even though we have the msdos filesystem in the
kernel.
However, I've taken a quick look at it, and I do have some
warnings:
*) It looks like upstream hasn't released a new version since July or
August 2002. Before that, releases were happening regularly. Is the
author Keith Sheffield (cc'ed on this note), still maintaining the
package?
*) It badly needs to be autoconfiscated.
*) Currently it hardcodes the path to static libraries in
../e2fsprogs-1.27/lib/...; it should use the shared version of the
libraries.
*) It's missing man pages
*) It needs testing against a variety of newer versions of ext2fs to
make sure the code actually works well with filesystems with htree
filesystems and extended attributes. Upon brief inspection, I can see
that it's not dropping the refcount on the extended attribute block
when deleting a file, and freeing the extended attribute block when
the refcount goes to zero.
This is no shame; it merely shows the age of the code, and to be
honest, the rm function in debugfs doesn't do this correctly either
--- I'll put that on my "to fix" list. However, there is the implicit
promise thatuserland packages such as e2tools will work correctly,
whereas debugfs sets a much lower level of expectations, since it's
assumed to be a wizard-level tool, with sharp pointy edges upon which
naive users can hurt themselves if they are not careful.
What it *does* show is that e2tools badly needs a test suite, which
takes a bunch of filesystems, does various e2tools operations on it,
and then runs e2fsck on the filesystem to make sure the resulting
filesystem is still valid. I have not run any tests on it, so I can't
be sure the extended attribute block handling is the only issue. I
*think* it should be just fine with htree directories, since the
libext2fs library handles a lot of the issues automatically. But
until you run tests --- preferably automated test suites --- you can
never be sure.
The bottom-line is that e2tools shows a lot of promise, but there's
also a lot of work that could be put into it in order to improve its
quality. Perhaps upstream could be convinced to tackle some of the
work, or at the very least, accept patches that you feed back to him.
- Ted
Reply to: