OSDev.org

For short 'imagetools'.

Back when I started with OSDev, I wanted to use Grub as a bootloader. However, I found it very tedious and time consuming to have to attach to a loopback device to write a disk label, then disconnect and reattach at a specific offset for the first partition and then mounting/copying files... time I could have spent debugging and testing. I was using a shell script to automate parts of it, but it still wasn't that great and still required me to be superuser to manipulate a disk image. (Which otherwise wouldn't be needed because my emulator runs as a normal user.)

I decided to look into possibilities as to how to alleviate this problem, and eventually came across e2tools. It appears it has been abandoned, as the last modification was over five years ago. This was before the x86_64 boom so it wasn't portable to my architecture of choice, and I attempted to fix it. Overall I disliked the way it was built. Something about introspection of argv[0] to decide functionality just didn't sit right with me. I've decided to remake the same set of tools, but extend them to include support for as many file systems as Linux supports, including all of ext{2,3,4}, xfs, jfs, reiser{3,4} through the support libraries contained in their respective maintenance tools.

Assuming you would have a need for such a tool what things would you like to see in it?

Support for a simple ramdiskFS (like SFS or TFS or, hell, just a bare file entry list with contiguous data!)

PLUGINS!!!

Like being able to load a SO/DLL that you wrote for your own filesystem and being able to load and use it.(Preferably, without having to recompile)

earlz wrote:PLUGINS!!!

Like being able to load a SO/DLL that you wrote for your own filesystem and being able to load and use it.(Preferably, without having to recompile)

I'm pretty sure that this is a linux/BSD program only. Windows doesn't have the libraries, nor the capabilities to do anything like this.

Windows doesn't have the libraries, nor the capabilities to do anything like this.

What, specifically, are you referring to?

pcmattman wrote:

Windows doesn't have the libraries, nor the capabilities to do anything like this.

What, specifically, are you referring to?

e2fsprogs
xfsprogs
reiserfsprogs
resier4progs
brtfsprogs
mtools
hfsutils
hfsplusutils
dosfstools

need i go on?

If you actually completed this and made it stable, I would quite honestly love you long time.

gl I'm working on something similar in python. For the core I ended up with something remarkably similar to the VFS in my OS.

Probably the most loved formats would be FAT 12/16/32 & Ext3, as they are what's most commonly used (and if you support Ext3, you support Ext4, which - bar some features - is backwards compatible)

Edit:

I'm pretty sure that this is a linux/BSD program only. Windows doesn't have the libraries, nor the capabilities to do anything like this.

Erm, wtf? Image manipulation uses nothing more then the standard library, fopen(), fwrite(), fread(), fseek(), fclose(), strcpy(), memset(), and bitwise operations. I don't see why you think this isn't portable, as it is.

OrOS wrote:

I'm pretty sure that this is a linux/BSD program only. Windows doesn't have the libraries, nor the capabilities to do anything like this.

Erm, wtf? Image manipulation uses nothing more then the standard library, fopen(), fwrite(), fread(), fseek(), fclose(), strcpy(), memset(), and bitwise operations. I don't see why you think this isn't portable, as it is.

He means the libraries for specific file system handling. The tools for managing different filesystems (i.e. mkfs, fsck) on Linux come with libraries that have the filesystem manipulation code, which he's going to use instead of writing his own implementation. If you wanted to port the tools to Windows, you would need those libraries too. The problem is that Windows would never have those libraries, because disks don't act like files, so their only use would be for a tool like this, which seems not to exist.

The problem is that Windows would never have those libraries, because disks don't act like files

Actually, you can open disks for reading and writing on Windows. Heck, you can do it in Python on Windows if you want. You just need administrator privileges.

Although your point is valid, you lie Drives can be accessed as files using the internal naming scheme, ex: \\.\PhysicalDrive0

Edit: Argh, beat me to it matt

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.

*starts writing libtfs*

Troy Martin wrote:*starts writing libtfs*

s/writing/finding/

So is it TFS or PiranhaFS?