Open
Bug 88341
Opened 23 years ago
Updated 2 years ago
[RFE] support for file truncation (ftruncate, etc.)
Categories
(NSPR :: NSPR, enhancement, P3)
Tracking
(Not tracked)
NEW
People
(Reporter: darin.moz, Unassigned)
References
Details
Attachments
(2 files)
This request results from mozilla bug 86474, in which file truncation is needed
by the necko cache. Since the truncation system call varies across platforms this
is a definite candidate for inclusion in NSPR.
Under BSD/XOPEN_EXTENDED compliant unixen there is the ftruncate system call.
Under Win32 there is the SetEndOfFile system call. And, under the MacOS there
is the SetEOF system call. I have no idea what equivalent call BeOS or OS/2
provide.
beos...
#include <unistd.h>
extern int ftruncate(int fd, off_t newsize);
Comment 2•23 years ago
|
||
On OS/2, there is API DosSetFileSize:
ulrc = DosSetFileSize(hFile, cbSize);
Comment 3•23 years ago
|
||
Larry, I suggest that we get this done in NSPR 4.2.
Use the PROffset64 type for the new file size, i.e.,
only add the 64-bit version of this I/O method.
PRStatus PR_Truncate(PRFileDesc *fd, PROffset64 newsize);
or PR_SetEndOfFile, or PR_SetFileSize.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 4.2
Comment 4•23 years ago
|
||
Adding a new function requires bumping the minor version number.
Since this enhancement is requested by the Mozilla client team,
we need to land NSPR 4.2 Beta on the NSPR client tag/branch
first (bug 78471).
Reporter | ||
Comment 6•23 years ago
|
||
FWIW: I would prefer PR_SetEndOfFile. It would rely on a call to PR_Seek before
truncating at a specific offset, but that is really not a problem since
truncation at a specific offset is typically used before writing at that offset
(as is the case in mozilla/necko).
Consider the scenario on UNIX w/ PR_Truncate
PR_Seek(offset);
PR_Truncate(offset);
ftruncate(offset);
and on WIN32 w/ PR_Truncate
PR_Seek(offset);
PR_Truncate(offset);
prev = PR_Tell();
PR_Seek(offset);
SetEndOfFile();
PR_Seek(prev); // restore file pointer to previous value
now, consider PR_SetEndOfFile on UNIX
PR_Seek(offset);
PR_SetEndOfFile();
ftruncate(PR_Tell());
and, PR_SetEndOfFile on WIN32
PR_Seek(offset);
PR_SetEndOfFile();
SetEndOfFile();
using PR_SetEndOfFile definitely appears to result in fewer system calls on
WIN32 in this common usage scenario.
anyways, that's just my $.02
Comment 7•23 years ago
|
||
Because of Larry's departure, I won't be able to implement
this new function. If anyone volunteers to take this bug,
I will be happy to answer questions and review patches.
Comment 8•23 years ago
|
||
Darin, it seems that you are making a distinction between
PR_Truncate and PR_SetEndOfFile. I named them as two
possible names of the new function (to set file size and
extend or truncate as appropriate). I don't understand
your code samples and what your points are. I must
have missed the context for your comments. Sorry. Could
you explain?
Reporter | ||
Comment 9•23 years ago
|
||
my examples are meant to demonstrate what code would be run if NSPR exported a
PR_Truncate method or a PR_SetEndOfFile method for a common usage senario,
namely "truncate an open file to a specific offset and then start writing at
that offset."
in this usage senario, client code will naturally call PR_Seek before (or after)
either PR_Truncate or PR_SetEndOfFile, since that sets the write cursor. so,
for each platform we should consider what the underlying code looks like to help
us decide which function should be exported from NSPR.
in my examples (above) i've added extra indentation to the code NSPR would use
to implement PR_Truncate and PR_SetEndOfFile, and i think this shows that
PR_SetEndOfFile would be a more practical API (at least in this particular usage
senario).
anyways, i'd be up for cutting a patch once we decide on a good API.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: 4.2 → Future
Comment 10•23 years ago
|
||
I'll see if I can work up a patch next week.
Assignee: wtc → gordon
Status: ASSIGNED → NEW
Comment 11•22 years ago
|
||
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
Comment 12•22 years ago
|
||
Additional configuration suggestions in bug 162588.
Comment 13•22 years ago
|
||
This attachment is the listing of the Truncate() method as it's currently
implemented in the disk cache.
Comment 14•22 years ago
|
||
This attachment is an initial proposal for an NSPR version of the Truncate()
call. It hasn't been tested, and doesn't take into account I/O layers.
I'm proposing a variation on ftruncate() because that's what we're currently
using in the tree, and it doesn't require a seek() beforehand.
Updated•18 years ago
|
QA Contact: larryh → nspr
Updated•7 years ago
|
Priority: P1 → P3
Comment 16•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: wtc → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•