Fix FileHandle.truncateFile()

[DagAgren]

FileHandle.truncateFile() currently does not work. It attempts to do a lseek() to the requested file size, which is not required before calling ftruncate. Furthermore, it expects this call to lseek() to return 0, which only happens if truncateFile() is called with a 0 size. Thus, the function will only succeed if called to truncate the file to zero bytes. In other cases, it will silently fail.

[ianpartridge]

Thanks for your contribution! Can we improve the tests in this area at the same time?

[alblue]

@swift-ci please test

[alblue]

@DagAgren The change looks fine, but can you write some tests that exercise the new functionality, and verify it works as expected?

[alblue]

@DagAgren are you able to add the tests to verify your changes work as expected please?

[DagAgren]

Sorry, I don't have an actual setup to build the code. I made this change quickly through github when I noticed the code was wrong while looking it up.

[alblue]

@ianpartridge would you be able to add a test for this so that we can get it merged in?

[ianpartridge]

I'll have a go, yes.

[alblue]

@ianpartridge did you manage to get anywhere with tests for this, or should we just merge as is?

[nevil]

@alblue @ianpartridge @DagAgren

I created some basic tests for this change but noticed that the fix does not work the same as the Darwin implementation.

I had to change it like this:
https://github.com/nevil/swift-corelibs-foundation/blob/75b05c1d39d6fa395a47b12cb1bc9db254f158f0/Foundation/FileHandle.swift#L146-L149

Should I create a new PR with this implementation?

[kperryua]

@nevil The behavior of your implementation more closely matches that of Darwin's, which is documented thusly:

Truncates or extends the file represented by the receiver to a specified offset within the file and puts the file pointer at that position.

The only real bug in the original implementation of this method is that it expects a return value of exactly 0 from lseek.

[nevil]

@kperryua Should I go ahead and create a new PR with the updated implementation?

[kperryua]

@nevil Yes, please do.

[nevil]

@kperryua
Created #1532

Thanks!

[nevil]

#1532 has been merged so I think this PR can be closed.