Page 2 of 2

Re: Disk Image Manipulation Tool

Posted: Thu Jun 11, 2009 10:09 am
by whowhatwhere
*brainstorm*

I'm thinking of splitting the project into two parts: libquasifs, and imagetools. libquasifs is the 'vfs' wrapper around the libfs libraries provided by the linux utilities. Imagetools is obvious. It should also have the ability to select a set of operations for given filesystem and auto-detection of a partition's filesystem would be great. It would mean transparent access to each image and simplicity of configuration.
How do you think access to partitions should be accomplished? Hypothetically assuming that someone were to use this on an actual hard disk image, there are going to be multiple partitions, each with possibly different filesystems contained within, how would one structure the operations to/from the host disk?

1. $ imagetools [options] command local-file ./disk-image:pseudo-path-of-partition-number/absolute/path/into/disk
---- $ imagetools cp localfile.bin hard-disk.img:1:/tmp/localfile.bin
2. A interactive REPL prompt like FTP ?
---- > select image hard-disk.img
---- > select partition 1
---- > copy file.bin /tmp/file.bin
---- > commit


e2tools was fairly vague about this.

Re: Disk Image Manipulation Tool

Posted: Thu Jun 11, 2009 2:19 pm
by frank
The first one is much better. It would be easier to integrate into a script.

Re: Disk Image Manipulation Tool

Posted: Thu Jun 11, 2009 2:27 pm
by earlz
syntropy wrote:*brainstorm*

I'm thinking of splitting the project into two parts: libquasifs, and imagetools. libquasifs is the 'vfs' wrapper around the libfs libraries provided by the linux utilities. Imagetools is obvious. It should also have the ability to select a set of operations for given filesystem and auto-detection of a partition's filesystem would be great. It would mean transparent access to each image and simplicity of configuration.
How do you think access to partitions should be accomplished? Hypothetically assuming that someone were to use this on an actual hard disk image, there are going to be multiple partitions, each with possibly different filesystems contained within, how would one structure the operations to/from the host disk?

1. $ imagetools [options] command local-file ./disk-image:pseudo-path-of-partition-number/absolute/path/into/disk
---- $ imagetools cp localfile.bin hard-disk.img:1:/tmp/localfile.bin
2. A interactive REPL prompt like FTP ?
---- > select image hard-disk.img
---- > select partition 1
---- > copy file.bin /tmp/file.bin
---- > commit


e2tools was fairly vague about this.
both!
using the 2nd method if there is a -i (interactive) flag

Re: Disk Image Manipulation Tool

Posted: Thu Jun 11, 2009 6:27 pm
by pcmattman
syntropy wrote:I think it would be much simpler just to use what is already there instead of reinventing the wheel. I do know of a few mingw32-based remakes of libext2fs, but I still am lacking the windows programming experience.
If you complete it, I'll port it to Windows. Of course, only if you really want that though.

Re: Disk Image Manipulation Tool

Posted: Thu Jun 11, 2009 10:12 pm
by whowhatwhere
I'm wondering about if I should support resier(3|4)fs. Have they fixed the image-within-filesystem-trashing-entire-partition bug yet?
As well, what other features would you like to see in it?

EDIT: Well it seems I'm going to be cut short. There actually aren't that many filesystem libraries. Why people would develop filesystems and not the access libraries is beyond me, but I don't have the experience for developing them myself. If anyone would like to volunteer for libraries for filesystems other than XFS, Resier(3|4), and Ext(2|3|4), be my guest.

Re: Disk Image Manipulation Tool

Posted: Fri Jun 12, 2009 12:38 pm
by whowhatwhere
Apologies for the double post.

I've set up a repository on repo.or.cz, here. The 'mob' branch is enabled, so anyone that would like to contribute, please feel free to do so. Once I've got something viable to commit to the master branch, I will do so.