Your use of truncate() doesn't make sense in context.
As noted in the comment, seek( FH, 0, SEEK_END ) will seek to the end of the file. But truncate( FH, 0 ) will then truncate the file to size 0. This means your seek position will now be past the end of the file (unless the file had already been empty). This means that when you next write to the file, nil bytes will be used to fill the first part of the file up to the point of your seek position.
I could see a point of opening the file in a manner that doesn't truncate for the explicit purpose of only truncating the file after you have obtained a lock. In such a case, I don't see how seeking to the end of the file would make sense.
I could also see the point of seeking (perhaps by reading) to a point in the file and then truncating from that point on before writing. In such a case, you would not pass 0 as the 2nd argument to truncate(). And that only makes sense if the seek point might not be the current end of the file.
I hope that helps to clarify things for you.
See also truncate,2.
- tye
In reply to Re: Bareword "SEEK_END" not allowed while "strict subs" in use (truncate)
by tye
in thread Bareword "SEEK_END" not allowed while "strict subs" in use
by thanos1983
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |