DECC RTL strikes again: ftruncate()

[David Jones_21]

The documentation's description of ftruncate() seems plain enough (one line), yet the function does not do what it says unless it is the last thing you do before closing the file.

It probably wouldn't occur to me to sequence the operations as (truncate, seek, write, close) if I wrote the application, but I occured to coder unix originated code I'm trying to run on OpenVMS.

[Hein van den Heuvel]

>> The documentation's description of ftruncate() seems plain enough (one line)

Hmmm, I see a small page full.

What specific version? ( $ cc /ver )

The program specifies shr=upd, that's only effective with ctx=rec, forcing record mode no?
When a file is in record mode you can only seek (and truncate) to prior record start address, typically returned by ftell.
As the program does not check the truncate nor seek results it my get surprise results.

Also, the truncate is a no-op is it not?
Assuming it worked, it is then overrules with the seek+write sequence which is effectively an other truncate at byte 0.

anyway... it seems to work for me.
Tested on: HP C V7.3-018 on OpenVMS IA64 V8.3
And: Compaq C V6.2-003 on OpenVMS Alpha V7.2-1

I replaced the buffer sizes with 10 and 20, and I filled the buffer with 11111 and 2222 to show where the data comes from, and printed the trucate and seek status

It gives:

$ cc test
$ link test
$ run test
Initial size of file is 0
Initial size overwritten of file is 20
truncate: 0
lseek : 0
Wrote 20 bytes to file, then 10 bytes after truncate
$ type test_ftruncate.tmp
2222222222

Leaving the truncate, but removing the seek I get:

Initial size of file is 20
Initial size overwritten of file is 20
truncate: 0
Wrote 20 bytes to file, then 10 bytes after truncate
$ type test_ftruncate.tmp
11111111112222222222

This suggests to me that the truncate works fine.


hope this helps some,
Hein.

[David Jones_21]

>Hmmm, I see a small page full.

The desription section in help is one line. In the VMS 8.2 C runtime library reference, the description is 5 short sentences, one of which is: "If the file was previously larger than length, extra data is lost."

>What specific version? ( $ cc /ver )

HP C V7.3-009 on OpenVMS Alpha V8.2

>The program specifies shr=upd, that's only
>effective with ctx=rec, forcing record mode
>no?

I meant to change that argument optionally from the command line, but forgot. When I add the change, I still see the same result even with something innocuous like deq=0.

>As the program does not check the truncate
>nor seek results it my get surprise results.

The lseek is to the beginning of the file, always allowed.

>Also, the truncate is a no-op is it not?
>Assuming it worked, it is then overrules with
>the seek+write sequence which is effectively
>an other truncate at byte 0.

The intent of the programmer was that a file that started at x bytes of state data will have y bytes updated state data when finished. If y is less than x, ftruncate() is called to shorten the file, but the file is not getting shortened.


>$ run test
>Initial size of file is 0
>Initial size overwritten of file is 20
>truncate: 0
>lseek : 0
>Wrote 20 bytes to file, then 10 bytes after truncate
>$ type test_ftruncate.tmp
>2222222222

Delete test_ftruncate.tmp and run the program twice in a row. Is initial size of file 10 or 20? The type command isn't displaying the 10 NULs at the end of the file, but stat() reports them in the file size so the program assumes there are 20 bytes of valid data.

[Hein van den Heuvel]

The EOF bytes seems wrong, the data right?
Have to check again with more time...
In my amended example, there are no zeroes but recognizable ascii data to prove that.

gotta go now...
(Las Vegas, presenting at HP Tech Forum)

fwiw,
Hein.

[David Jones_21]

> The EOF bytes seems wrong, the data right?

The bytes between old length and the new length argument are set to zero, but that rule only applies "If the file was previously shorter than length bytes, ". There is not supposed to be any data, zero or otherwise, to read.

>(Las Vegas, presenting at HP Tech Forum)

Enjoy your stay.