Last Comment Bug 162588 - Some non-tier1 platforms may lack file truncation...
: Some non-tier1 platforms may lack file truncation...
Product: Core
Classification: Components
Component: Networking: Cache (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: ---
Assigned To: gordon
: Tom Everingham
Depends on:
  Show dependency treegraph
Reported: 2002-08-13 16:13 PDT by Darin Fisher
Modified: 2004-07-20 04:45 PDT (History)
3 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Quick fix (1.97 KB, patch)
2002-11-06 02:48 PST, hacker formerly known as
gordon: review+
darin.moz: superreview+
Details | Diff | Review

Description Darin Fisher 2002-08-13 16:13:17 PDT
from the security review notes:

  "Some non-tier1 platforms have the problem that if we cache a file, then go
   see the site again and the file has become smaller, we don't erase the 
   difference. This could result in a situation (example) where I go to
   ecommerce site, view item on sale where default amount to buy is 10, come
   back a week later, page smaller (no longer possible to state how many to
   buy), I buy item, but accidentally by 10 items because the old page
   contained amount information."

we should either make adding PR_Truncate higher priority or simply add a
preprocessor #error message to prevent platforms which lack support for file
truncation from building.  this would help maintainers of the various "broken"

marking security sensitive... this is probably just dependent on some other bug(s).
Comment 1 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2002-10-15 08:56:17 PDT
This seems minor but we might as well fix it. CCing seawood for help. We should
probably take the path of least resistance and refuse to build if we don't have
a usable truncate().
Comment 2 hacker formerly known as 2002-10-15 10:27:26 PDT
Is the problem that truncate() passes but doesn't actually truncate the file or
that truncate() always returns an error condition?  Right now, we appear to use
truncate() without any checks so platforms without any truncate() support would
fail anyway.  And do we have a workaround for those platforms with a broken

Comment 3 Darin Fisher 2002-10-15 10:32:03 PDT
seawood: we call ftruncate for XP_UNIX builds.  any non-XP_UNIX builds have
special code to call ftruncate.  if some non-XP_UNIX build is not covered by our
#ifdef's then the files will not be truncated.  no function call, no truncation.

we need to make sure that for all platforms, there is a call to truncate the
file.  what about XP_BEOS?  i'm guessing it picks up the XP_UNIX #ifdef?  what
about other platforms?  thx!
Comment 4 hacker formerly known as 2002-10-15 13:05:02 PDT
Oh.  I was looking at the truncate call at .  Since
it's the system's truncate, it should have the same behavior as ftruncate (I
think).  Assuming that truncate/ftruncate work correctly if they exist, we can
just add this one liner to to mandate these functions:

AC_CHECK_FUNCS(truncate ftruncate,,AC_MSG_ERROR([Your operating system does not
support truncate and/or ftruncate. Exiting.]))

BeOS is an anomaly.  It's not a unix variant but it contains a number of POSIX
compliant APIs which are usually associated with unix (eg, it does have
ftruncate & truncate).  BeOS does not set XP_UNIX; it uses the separate XP_BEOS
define.  All of the platforms, expect win32 (which doesn't do feature tests) &
mac classic, should be covered by adding the function check.
Comment 5 Darin Fisher 2002-10-15 15:23:20 PDT
then BEOS definitely has this bug.
Comment 6 gordon 2002-10-15 15:44:58 PDT
...but it sounds like it should be easy to fix.  Once I add the AC_CHECK_FUNCS
line, I should be able to add '| XP_BEOS' to the XP_UNIX implementation.  Right?
Comment 7 hacker formerly known as 2002-10-16 00:07:50 PDT
Once you add the configure test, you should replace the XP_UNIX ifdef with a
HAVE_FTRUNCATE ifdef.  For the non-unix platforms (namely win32 & OS/2), should
you be using ftruncate, if it exists, or keep the existing truncate functions?

At this point, it only really sounds like BeOS was the only OS that isn't being
covered by the existing ifdefs so adding the || XP_BEOS would be the quick fix
to avoid adding the configure test.

Comment 8 gordon 2002-10-16 15:13:42 PDT
What are the issues with adding a configure test?  It seems like that would be
the correct way to go.  Does it kick off a clobber build?
Comment 9 hacker formerly known as 2002-10-16 17:53:54 PDT
There are no real issues with the configure test except that it may fail for
some non-unix platforms (namely OS/2) which you already cover with the other
ifdefs.   Adding the defines will cause the entire world to rebuild once (but
that's not really a problem).
Comment 10 Mitchell Stoltz (not reading bugmail) 2002-11-04 15:44:41 PST
Sounds like we've got a fix. Gordon, is it ready to be posted here and reviewed?
Comment 11 hacker formerly known as 2002-11-06 02:48:18 PST
Created attachment 105314 [details] [diff] [review]
Quick fix
Comment 12 Mitchell Stoltz (not reading bugmail) 2002-11-25 16:35:47 PST
Let's get this reviewed and checked in for 1.3a.
Comment 13 Darin Fisher 2002-11-25 16:41:46 PST
Comment on attachment 105314 [details] [diff] [review]
Quick fix

Comment 14 gordon 2002-12-17 15:46:02 PST
Comment on attachment 105314 [details] [diff] [review]
Quick fix

Comment 15 hacker formerly known as 2002-12-18 22:28:14 PST
The quick fix has been checked in.
Comment 16 gordon 2003-01-03 16:46:37 PST
Okay, marking this fixed.  We have another bug to cover moving Truncate() into
NSPR. We can rework the config testing then.  See bug 88341.
Comment 17 Mitchell Stoltz (not reading bugmail) 2003-06-19 15:55:47 PDT
adding to CC list
Comment 18 Daniel Veditz [:dveditz] 2004-07-20 04:45:48 PDT
Bugs published on the Known-vulnerabilities page long ago, removing confidential

Note You need to log in before you can comment on or make changes to this bug.