Re: Delete a file THAT big? Surely you are joking.

[prev] [thread] [next] [lurker] [Date index for 2006/12/18]

From: Martin Ebourne
Subject: Re: Delete a file THAT big? Surely you are joking.
Date: 17:16 on 18 Dec 2006
Yossi Kreinin <yossi.kreinin@xxxxxxxx.xxx> wrote:
> This is very sweet of Unix.
>
> * Why is it sensible to allow to truncate a file someone has opened?

It's entirely reasonable two processes should be able to write to a file.

> * Especially if you don't allow to remove such files?

Oh, you can remove them alright.

> * Or, more specifically, you ALLOW to remove such files, but not to =20
> reclaim the disk space?

Obviously the disk space can't be reclaimed, because a process has a =20
file open still. Therefore it could reasonably expect to be able to =20
read from it, and the data has to come from somewhere. Or should the =20
OS just make it up?

> * And how am I supposed to know which process is using the file?

We've covered that already. I'm sure you've read the man page by now.

> For instance, Unix will let you overwrite a shared object used by a =20
> process, and the process will crash. Isn't it *hateful*?

Yes, it's hateful when that happens and a process crashes, but then =20
you shouldn't open the same file and make changes to it. It's hateful =20
when you hit your thumb with a hammer, but what can I say? You should =20
delete the file and then create a new shared object in its place. Then =20
you'll see why the way unix does this is right, and the way certain =20
other OS's do this is wrong. If that shared object being in use =20
prevented you from opening it, removing it, or replacing it that =20
really would be hateful. Having used windows I speak from experience =20
on that one.

As it is I can upgrade my linux machine to a completely new version of =20
the OS while still happily using it. When the upgrade is complete I =20
reboot at my convenience to be sure it is all running sweetly. None of =20
this booting off a cd and having an hours downtime crap. There's 100s =20
of other perfectly good uses of this feature.

Now what is hateful about this whole situation is that unix has =20
fifteen different ways of locking a file to prevent multiple processes =20
from using it when this is important. Alas, they generally don't work =20
with each other and most don't work over nfs. This is a truely =20
shocking state of affairs, but is way too easy to hate so I'll just =20
groan instead. Sigh.

Cheers,

Martin.
There's stuff above here

Generated at 03:01 on 20 Dec 2006 by mariachi 0.52