Kerry Baker wrote:
I need to know the actual procedure the file system uses to delete a file.
That is, what files are modified (Inode table, SuperBlock, Group Descriptors etc) and 
which fields within the files are modified.

Do you want to "know" what happens, or to have a technical reference?

What happens is driven by the unlink system call ... try 'man 2 unlink' - but then it is mediated by the underlying filesystem. I think you may have to read the code for the relevant parts of the kernel/module to be 100% sure.

When removing a file, the name/inode reference in the parent directory file is deleted (directories are basically ordinary files, although most unixes try to prevent you from seeing them - BSD does not worry about this)

[EMAIL PROTECTED] DualScreen$ od -c .
0000000   \0   [ 016  \0  \f  \0 004 001   .  \0  \0  \0  \0   /   X  \0
0000020   \f  \0 004 002   .   .  \0  \0 001   [ 016  \0 024  \0  \b  \t
0000040    .   D   S   _   S   t   o   r   e  \0   n 334 002   [ 016  \0
0000060  030  \0  \b 017   A   r   r   a   n   g   e   m   e   n   t   .
0000100    p   d   f  \0 003   [ 016  \0 030  \0  \b 016   D   u   a   l
0000120    S   c   r   e   e   n   .   t   x   t  \0  \0 004   [ 016  \0
0000140  034  \0  \b 023   D   u   a   l   S   c   r   e   e   n   s   a
0000160    v   e   r   .   j   p   g  \0 005   [ 016  \0 034  \0  \b 021
0000200    S   y   s   t   e   m   P   r   o   f   i   l   e   .   p   d
0000220    f  \0 020 334 006   [ 016  \0 034  \0  \b 020   V   G   A   c
0000240    o   n   n   e   c   t   o   r   .   j   p   g  \0 364 020 334
0000260   \a   [ 016  \0   P 001  \b 017   A   r   r   a   n   g   e   m
0000300    e   n   t   .   p   n   g  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000320   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0001000
[EMAIL PROTECTED] DualScreen$ ls
Arrangement.pdf         DualScreen.txt          SystemProfile.pdf
Arrangement.png         DualScreensaver.jpg     VGAconnector.jpg
[EMAIL PROTECTED] DualScreen$

At this stage, we know the inode number of the file that is being removed, so we can go to the ilist and decrement the use counter for it. If the use counter hits zero, the inode data is deleted, and the blocks the file was occupying become free (i.e. as they are no longer referenced, they are available for use)

Note that having a file open in a running process increases the inode use counter, so it's possible to delete all references to the file on the filesystem as seen through directory entries, but for the file to still exist. This is the sort of thing that trips up people who delete a large apache logfile, and don't see any more available space on their filesystem ... they need to interrupt the apache process as well.

Now, I must admit that you were asking "what happens in ext2", not "what happens in general", and I can't tell you how and when ext2 decides to reuse blocks that are not referenced in the ilist ... so perhaps I haven't helped you at all ...

-jim

Reply via email to