On Sun, 4 Jan 2009 18:39:10 +0530
"Paraneetharan Chandrasekaran" <paraneetharanc@xxxxxxxxx> wrote:
> Hi All,
> I created a file of 10 MB from /dev/zero using dd command.
> Then i associated /dev/loop0 to that file using losetup command. Then
> i created an ext2 filesystem above /dev/loop0 using mke2fs command.
> Then i mounted the that loop device in a mount point. I entered the
> monted directiry and created on file and entered some contents to that
> file. Then i came out of the directory. Then i deleted the file i
> associated. Then If i go inside the mounted directory, i was able
> change the directory and the file was there with the contents i put.
>
> how is that possible when deleted the file itself inside which i
> created the ext2 filesystem..? I was previously thinking that the VFS
> reads from the file itself for files and directory info. is it not
> like that..? I have even cleared the buffers after i deleted the
> file(using sync).
When you unlink file - directory entry(dentry) is deleted from directory
structure immediately (metadata operation). So you can't open deleted file by it's old _name_.
Inode (structure, holding info about physical blocks belonging to associated file) is
deleted when there is no more references to it.
References can be:
* on disk (hard links)
* in-memory descriptors (files currently opened by process(es))
Thus you can safely use code like this:
...
char tmpl[] = "/tmp/tmp.XXXXXXXX"
int fd = mkstemp (tmpl); /* create inode and dentry */
(assert fd != -1);
unlink(tmpl); /* delete dentry */
/*
* Do something with fd: read/write
*/
close(fd); /* delete inode */
...
Moreover, you can get access to this (deleted) file until process exits or closes file.
You could play with it (prompt 1 emulates losetup, prompt 2 emulates your actions):
prompt1$ cat > /tmp/z
FOO
BAR
<leave it running>
prompt2$ rm /tmp/z
$ls -l /proc/*/fd/* 2>/dev/null | grep /tmp/z
l-wx------ 1 slyfox slyfox 64 Янв 4 18:39 /proc/22665/fd/1 -> /tmp/z (deleted)
$ cat /proc/22665/fd/1
FOO
BAR
But!.
My examples are userspace reference holders and they are visible via /proc/*/fd,
losetup (or mount -o loop), in contrast, increments reference count
to associated file differently - via ioctl() call.
You can observe dark magic by `strace'ing losetup command:
# strace losetup /dev/loop0 /etc/fstab
....
open("/etc/fstab", O_RDWR|O_LARGEFILE) = 3
open("/dev/loop0", O_RDWR|O_LARGEFILE) = 4
....
ioctl(4, 0x4c00, 0x3) = 0 // ahha, that's it! We ask kernel to do something nasty with this descriptor
close(3) = 0
ioctl(4, 0x4c04, 0xbf9c0624) = 0 // and here too
close(4) = 0
....
/usr/include/linux/loop.h:#define LOOP_SET_FD 0x4C00
/usr/include/linux/loop.h:#define LOOP_SET_STATUS64 0x4C04
So, your ext image file will be deleted right after you supply losetup -d /dev/loop0 (or umount)
Before this action you can play with /dev/loop .
>
> Thanks in advance,
> Paraneetharan C
>
--
Sergei
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
