ftruncate() bug with fop=dlt

[Craig A Berry]

The following little test program fails like so:

$ run ftruncate_bug
ftruncate failed: no such file or directory

I've opened the file successfully, written to it successfully, but when I call ftruncate on it, it thinks the file does not exist. When stepping through in the debugger, the file is definitely there before the call to ftruncate, but disappears before the function returns.

The only explanation I can think of is that in order to truncate a file to a length of zero, the CRTL is closing the file and opening a new version of it. Since the delete-on-close bit is set, the file disappears and something internal to ftruncate that depends on the prior version existing fails.

Can anyone with read access to the CRTL sources confirm that this is what is happening? Can anyone with write access to the CRTL sources make it stop? There is nothing in any ftruncate standard I can find nor in the CRTL documentation that says anything about the file being closed and reopened, and it turns out to have a nasty side effect in this case.

--- begin ftruncate_bug.c ----
#include
#include
#include
#include

main()
{
int file;
int flags;

flags = O_RDWR | O_CREAT;

file = open("ftruncate_bug.dat", flags, 0, "fop=dlt");
if (file == -1)
perror("open failed"), exit(1);

if (write(file, "Hello world\n", 12) < 0)
perror("write failed"), exit(1);

if (ftruncate(file, 0) < 0)
perror("ftruncate failed"), exit(1);

close(file);
}
--- end ftruncate_bug.c ----

[Hoff]

It does look like a bug.

If you're curious about what's going on, toss a SET WATCH /CLASS=ALL FILE at this, and also consider displaying errno and vmserrno after the failure.

I might choose to recode this sequence to remove the DLT option, and to replace this with the native C temporary file mechanisms. If not for portability, then simply for staying within the bounds of the various implementation sandboxes involved here.

[Craig A Berry]

Thanks, Hoff. SET WATCH gives me:

$ r/nodeb ftruncate_bug
%XQP, Thread #0, Access FTRUNCATE_BUG.EXE;5 (97633,45,0) Status: 00000001
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Create/Access FTRUNCATE_BUG.DAT;1 (94085,462,0) Status: 00000001
%XQP, Thread #0, Control function (94085,462,0) Status: 00000001
%XQP, Thread #0, Final status: 00000870
%XQP, Thread #0, Modify FTRUNCATE_BUG.DAT;1 (94085,462,0) Status: 00000001
%XQP, Thread #0, Delete FTRUNCATE_BUG.DAT;1 (94085,462,0) Status: 00000001
%XQP, Thread #0, Deaccess (94085,462,0) Reads: 1, Writes: 2, Status: 00000001
%XQP, Thread #0, Access (94085,462,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
%XQP, Thread #0, Lookup (0,0,0) Status: 00000910
%XQP, Thread #0, Access (0,0,0) Status: 00000910
ftruncate failed: no such file or directory
%XQP, Thread #0, Deaccess (97633,45,0) Reads: 5, Writes: 0, Status: 00000001

That confirms it deletes the file and then goes looking for it again. I don't see anything that tells me the delete comes from closing the file, but that's still the most likely explanation.

Naturally this is a greatly boiled down reproducer from a more complex situation involving code that is not mine, so simply replacing the open call with mkstemp or similar is not straightforwardly applicable.

[Hein van den Heuvel]

No access to the C-RTL sources right now, but it would seem to work the way you conclused.

Dunno why the CRTL would want to close aroudn a truncate. Sounds buggy.

The DLT bit is a little 'nasty' as once you set it for open or create, you can no longer un-set it (see RMS documenation below).

In dealign with the C-rtl weakness/bug, the code may have to drop the fop=dlt on the 'open', replace by 'acc=' to get a FAB to remember. When desired, flip the DLT bit on just before the close using the FAB from the acc callback. Yuck. What if the program does not get around to do the close huh?

Sound like the truncate is best replaced by a close + re-create, but that's very yuckie as well.

fwiw,
Hein.



http://h71000.www7.hp.com/doc/731final/4523/4523pro_005.html#index_x_240


FAB$V_DLT
Delete file on Close; indicates that the file is to be deleted when closed. This
option may be specified for the Create, Open, or Close services. However, if you
set the bit when you create or open a file, RMS deletes the file when you close
it, regardless of the state of the bit when you invoke the Close service. You can
specify the FAB$V_DLT option with the FAB$V_SCF or FAB$V_SPL option.

[David Jones_21]

The old 7.2 source listing (C RTL 5.6) show ftruncate as using SYS$TRUNCATE and no explicit open or close calls. I recall having problems with ftruncate in the past so it wouldn't surprise me if they rewrote to try to get its behavior closer to Unix semantics.

[David B Sneddon · Accepted solution]

Just had a quick look at the V8.3 sources and
there is code in there to save the delete on
close status, clear it, close the file and
reopen it and restore the delete on close bit...
The history shows the "change" was done in
September 2001

Dave

[David B Sneddon]

After having re-read Hein's comments, it would
appear that the person making the change was not
familiar with the DLT bit and how it works...

Dave

[Craig A Berry]

Thanks, guys. Looks like David S. has found the smoking gun. Too bad that CRTL programmer didn't have Hein looking over his shoulder. Of course actually testing your code can make up for a lot of ignorance. I prove myself ignorant that way all the time :-).