[10322] in bugtraq

home help back first fref pref prev next nref lref last post

Re: truncate("x", -1)

daemon@ATHENA.MIT.EDU (Pavel Kankovsky)
Thu Apr 22 13:27:59 1999

Date: 	Thu, 22 Apr 1999 17:49:53 +0200
Reply-To: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
From: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <19990420074119.A5976@caffeine.ix.net.nz>

On Tue, 20 Apr 1999, Chris Wedgwood wrote:

> >   truncate("x", -1)
...
> 2.0.x gets messed up. I've sent a patch to bugtraq and AlanC which I
> took from 2.2.x, so hopefully 2.0.37 will be OK.
>
> 2.2.6 is fine.

Does it fix the problem? I am not sure. The filesystem itself is
responsible for keeping the filesize in the bounds it can manage but there
is no guarantee the higher bound is the maximal (positive) off_t (on the
other hand, it makes sense to assume the lower bound is always 0 :> ).
The filesystem can check whether the new size is acceptable in its
notify_change method but most filesystems do not care (only the network
ones seem to bother to look at it at all). Even worse, a quick look at
some truncate methods (namely fat_truncate) made me think they are not
ready to make the file bigger anyway (well, I have to admit they made
me wonder whether they are able to work at all :P ).

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"

home help back first fref pref prev next nref lref last post