Re: [TCLUG:16067] problems with df/du mismatch

[Chris McKinley <lamfada@lugh.net>]

I think Windows is broken.  Windows has no concept of hard links, while all
current UNIX variants do.  Since all files are simply a hard link to the
inode, and an open file already knows where the inode is in the VFS, removing
the directory entry is OK.  It is always the kernel's job to determine when the
last link is removed, and free the inodes in use by the file.  Windows does not
do this correctly.  The commands fuser and lsof are what you should always
have on hand to determine what processes have access to files before 
removing them.

To take another pot shot at Windows, I have heard that some programs which
run fine on FAT have problems running on NTFS.  I do not have details, 
mostly because I do not really care, however that indicates to me that 
MS does not have a well defined / abstracted VFS layer to Windows, or if
they do, then it is not used by developers, which amounts to the same thing.

-Chris McKinley

On Wed, 12 Apr 2000 Nick.T.Reinking@supervalu.com wrote:

> Yup, this is how all UNIXes work.  What happens is that
> doing an rm clears the directory entry for it, but it doesn't
> clear the inode(s) until the process that has a flock on the
> file (apache) releases it.  Windows, AFAIK, won't let you
> remove a file that is currently in use.  I think this might be the
> correct behavior, but I can't say for sure.  (Sometimes it's
> highly annoying, sometimes it's useful.  The biggest problem
> is when a process dies, but it doesn't clear out that processes
> locks, and so it won't let you remove it, but you can't clear the
> locks, either - argh!)
> 
> Nick Reinking
> 
>