[lkml]   [1999]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deletion of big files...
   Date: 	Mon, 17 May 1999 03:23:56 -0400 (EDT)
From: Alexander Viro <>

I'm not sure... Look: we spend time *not* in unlink() pre se. It's a final
truncate(). And at the moment when it's called we *know* that we are sole
owners of the thing and nothing else will ever try to touch it.

Careful here. One the reasons why truncate is so complicated is that we
are *not* always the sole owners of the file. This comes up because
truncate() isn't just called from unlink. It can also be called from
ftruncate(), or from open() with O_TRUNC. A lot of the hair in
truncate() is to deal with the case where another process as file
descriptor open the file and is actively writing while truncate() is
getting called.

The right thing to do here is to replicate the truncate function so that
there's one version that's used for unlink(), where you can make all
sorts of simplifying assumptions, and one version which is used in the
more general case. This way, we can also get secure delete working as
well. (Secure deletition was one of the casualties that got eliminated
from truncate() when dealing with some of the race conditions that could
happen when it was called out of ftruncate() or open(O_TRUNC).)

- Ted

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.187 / U:7.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site