The file-based loopback device: making a file act like a disk
Linux offers something interesting called a loopback device that can be used to implement an entire filesystem within a file, by making the file behave as a device. Inscribing a filesystem on a device (eg, floppy or hard disk) is familiar. It's called formatting. In linux the mkfs command does it. Then you mount it and can write files onto it. Here, a file is made to appear as a disk device. Once that's accomplished, you can format and mount it just like any other device.
How to make a normal disk file appear to be a block device like a disk? Whatever you normally write onto a disk to make it work-- filenames, directories, inodes, timestamps, content-- can be written into a file. Disks and files are both just data-receiving containers. If you would format a disk by writing special stuff onto it, why not "format" the file by writing the same stuff? Thereupon you can pretend the file is a disk and use it as such.
Loopback device - make a file look like a disk
The hands-on recipe:
1. we need to have a file to work with, first of all
2. we need to associate that file with some device
3. we need to make sure the content of the file is structurally proper,
and contains the same kind of stuff (a directory, etc.) as a real disk
4. we need to integrate (mount) this pseudo-disk into the regular
hierarchical file tree, exactly as with a real disk
5. we can now use the filesystem freely throughout a session, till ready to finish
6. we need to detach (unmount) our file-based subdirectory from the
regular hierarchical tree
7. we need to dissociate the file from the device as which it has been
masquerading
How do we get the file? Well actually any file will do, but at some point we will have to assure it contains the same internal structures as does a real disk. Either the file starts out that way, or there's a step to make it that way. First case, suppose you had an existing floppy disk with a couple of files on it. You can take an exact copy of the floppy and put it into a file with the dd command. Here's such a floppy in Windows:
Inserted in the floppy drive of a linux machine, this command gives us our file:
dd if=/dev/fd0 of=myfloppy.img
Second case, we artificially generate a file, also using the dd command, something like
dd if=/dev/zero of=myfile bs=1024 count=1024
"if" is the input source, "of" is the output destination. The latter command uses /dev/zero as the source. /dev/zero is a special device whose content is an endless stream of hexadecimal zeroes. This time we specified the desired file size in the command, asking for blocks (bs="block size") of 1k bytes to be written out and stipulating we want 1024 of them. That's a total of 1,048,576 bytes (one megabyte). This file would be smaller than the floppy-image file, whose size is of course that of a floppy or about 1.4 megabytes. And this file will be full of pure zeros. It will internally lack a directory and other needed structures. By content, it won't look like a disk. The floppy-image file by contrast will look exactly like a disk since its content is that of a disk. This "myfile" file needs the right stuff written into it (mkfs does that later).
So our options were to start with a disk and turn it into a file, or make a file and turn its content into a disk. Either way, now we've got our file (two of them). Step 2 says we need to associate it with a device. That's the job of losetup or "loop device setup." We might as well associate both of our files with some devices. Which devices? There are special devices for the purpose whose names are /dev/loop0, /dev/loop1, and so forth. The command format is
losetup <name of loop device> <name of file to associate with it>
And in the case of a file needing proper filesystem structures written into it, the command thereafter is something like
mkfs -t vfat /dev/loop1
Below, the two loop devices are set up. Then they are queried to reveal whether they are actively associated with files, and which files. Then we make a filesystem (mkfs) of Microsoft's FAT32 type (vfat) in the pure-zero file. It too now contains a useable physical filesystem. Note the mkfs procedure is exactly as normally applied to an actual disk device. mkfs is presented with a device no different from normal, as far as it's concerned. It doesn't know that what's "inside" the device is a file any more than it knows when formatting a thumb drive that the device contains NAND flash chips or when formatting a hard disk that it contains metal platters.
Now we can integrate these two pseudo-disks into the file tree if we have places to put them. We'll create and utilize /mnt/first and /mnt/second.
To the mount command, like mkfs earlier, these are perfectly regular devices. We know they are ultimately files, but the commands don't. And the content of the first device is what our original floppy contained while that of the second one is null, having been freshly formatted with no further activity. It's time now for further activity. That's Step 5, the one you came for. You can use these subdirectories as you like, writing and reading and creating and deleting files in them. The actual destination to which your stuff will be written is somewhere inside of one of the loopback files (myfloppy.img or myfile). But that is transparent. And if you ever move a copy of those files to another machine, you can plug them into its tree and have all that they contain over there.
When you're done, steps 6 and 7 close up shop, unmounting the device and then dissociating it from its file.
In before-and-after fashion, the files are visible and the device "looped," then the files are gone and the device info lost. Easy come, easy go.
In particular, easy go. If you transfer this file that now holds an entire implicit filesystem to a different computer, you can as easily mount it and put that filesystem to use there.