[Novalug] smart deletion

Jason Kohles jason@nova-labs.org
Thu Sep 11 16:39:09 EDT 2014


The way it works is that there are actually several different things involved here.  First and foremost you have the actual data on the disk, the contents of the file.  Then you have an inode, which holds some of the metadata for the file, the inode includes things like the ownership, permissions and file type.  The inode also has pointers that indicate which blocks on disk represent the file data.  The main thing that the inode doesn't have is the name of the file.  Within the filesystem structure you have dentry's (dentries?).  A dentry (short for 'directory entry') relates filenames to inodes.

When you invoke your editor, the process it goes through (or that the system goes through on it's behalf) is:
- look at the filename provided (in your case 'fx')
- find the dentry that refers to that filename
- find the inode that refers to the actual data
- open a filehandle to that inode
- return the file handle

So, once the editor has the file open, the filehandle that it is using for access continues to refer to the same data, even if the dentry changes.  This can be important because some programs will open and modify the file itself, which can be very bad for some types of files, depending on how they are normally accessed.  The way that text editors normally do it is to write a new file and then rename it, so you have entirely new blocks on disk, entirely new inodes, you just replaced the dentry with one that points at your new file.

This dentry->inode mapping is the same thing that makes hard links possible, in that case you have multiple dentries that point at the same inodes.
 
-- 
Jason Kohles - Vice President - Nova Labs, Inc.
jason@nova-labs.org - www.nova-labs.org
Rediscover the joy of making things!

On Sep 11, 2014, at 4:09 PM, Gary Knott via Novalug <novalug@firemountain.net> wrote:

> If you run some program P that opens and reads
> some file, say fx,  and then while fx is still open and being read,
> you run an editor and change and save fx,  then:
> (1) the directory entry for fx is changed, and any program that
> opens and reads fx will get the new file.
> (2)  the program P continues to read the old version of fx.
> (3) somehow the blocks that comprise the old file fx
> will be reclaimed for re-use when it is safe to do so.
> 
> Q:  how does this work?   I have one idea:
> 
> 1. when the editor calls to delete fx  (I think the call is unlink(...))
> the OS detects that fx is open, and puts its inode and open-file-pointer
> (id)
> on a list of files to be deleted when they are closed.
> 
> 2. Then the directory entry is changed to link to the new
> file.  (how is this done?)
> 
> 3. Then when the open defunct file fx is closed, (explicitly
> or implicitly when the program P is killed,)  a check is made
> as to whether that file is open anywhere  (how can we know? -
> there must be a  table of file-pointer vs. inode?)
> And if it's not, then the blocks are reclaimed.
> 
> But there are some holes in this scenario, and
> several other situations that need to be covered.  Can anyone
> explain how it really works, or point to a story that explains it?
> 
> - gary knott, garyknott@gmail.com
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
> 
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug




More information about the Novalug mailing list