OSDev.org

There is an article in the wiki that describes how to handle image files under Unix systems.

I have two problems with that:

1) In several places, the article is needlessly complicated. Most operations described therein can be done without setting up a dedicated loopback device. The 'fdisk' command under Linux can operate on files, 'mount' knows both the '-o loop' and the '-o offset=<...>' option. I started streamlining the article, then hesitated - is there any reason for the 'losetup' hoops the author is jumping through?

2) While the article gives a good idea how to handle image files under Unixes, and is linked as such from the main page, it is named "Loopback Devices". If I entered that as search keywords, a tutorial on setting up an image file with 'dd' and formatting it with 'mkfs.ext2' might not quite be what I was looking for (as mentioned on the discussion page). I'm not the person to write a page discussing loopback device architecture, but I'd suggest renaming the article (perhaps "Image files under Unix"), to avoid confusion and to make room for a potential article on loopback devices themselves.

The thing is that not all tools support disk images. The only thing losetup does is turn a file into a block device so that you can use it whenever you would try supplying a real disk. The various mkfs.* tools don't like regular files - they either prompt, require special switches, or even blatantly call the user stupid and refuse to work. Similarly, mounting wont work without (implicitly) using a loopback device - the magic mount is just syntactic sugar to avoid manual calling of losetup.

And for a lesser problem (probably a non-issue in your opinion), you have the users that expect the block device behaviour when using dd (as in not being able to write past the end of device, no truncation). And for the dirty hackers around, try to find out why program X does not work when called with a regular file rather than a device.

Well... If you put it that way. I usually strip tutorials to the minimum number of lines, steps, and generally "things involved", but I see where your argument is coming from.