This functionality can be used to speed up any kind of software that uses the existance/manipulation of a file as a marker. If it's a hard link to some kind of 'hitching post', then it doesn't have the overhead of clearing up after itself, just removing the directory entry. It was quite a dramatic improvement for me, but it was a long time ago - on 68010 based machines to give you some idea.
Steve On Fri, 21 Jul 2006 11:43:49 +1200 Volker Kuhlmann <[EMAIL PROTECTED]> wrote: > > [sheppaap]# touch demofile > > [sheppaap]# ls -i demofile > > 18730 demofile > > [sheppaap]# unlink demofile > > > > As I know the inode, can I get that connection back or recreate the > > link between the filename and the attributes? > > A file's data and its directory-related matadata are two different > things in Unix. When a file is created, the link count is one. When you > add a (hard!-)link to it, the count is increased, when you delete a > "file", the count is decreased. When the count reaches 0, the data > belonging to the inode is deleted and the disk space freed. > > In your example, the link count reaches 0 after your 3rd command, the > inode is then free for use by another "file". > > As a special trick, data is not deleted (ans space freed) until the last > open file descriptor belonging to this data is closed. Security > conscious applications can use this to create and empty file, open a > descriptor to it, delete the file, and keep working. No file operations > other than duplicating the descriptor can access the data. Obviously > when the program exits the kernel with auto-close all descriptors (and > free the disk space). This is a possibility to investigate when you have > a gross mismatch between disk space taken up by files, and what should > be left as being free. A reboot would fix this too of course. > > Volker > > -- > Volker Kuhlmann is list0570 with the domain in header > http://volker.dnsalias.net/ Please do not CC list postings to me.
