Instead of being relatively coy about what you are importing:

use Fcntl qw(:flock)­;
[download]

Just be explicit, and the problem goes away:

use Fcntl qw< LOCK_EX SEEK_END >;
[download]

(And your code becomes clearer.)

To: tye,

Damn I forgot this part, completely. Thanks for pointing out.

Can you help me also unserstand a bit the truncate() part?

I have some questions and I do not know if I am correct or wrong, since is the first time that I am applying that. I have written a short exaplanation on my initial question at the end.

Again thank you for your time and effort

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.

To: tye,

Ok, starting to make more sense.

My plan was to use flock() to lock the file while my process will be either reading or writting to it. I want to avoid 2 processes together reading and writting simultaneously which will result on overlaping.

So my plan was to lock the file seek to the end of the file so I can write the next part of my output, close the file and allow the next process to write on it.

I was under the impression that I have to use truncate to empty the rest of the file at the end, to make sure there is nothing left besfore start writting.

I got this idea from the tutorial File Locking where they use both:

seek(MYFILE, 0, 0);
truncate(MYFILE, 0);
[download]

This is my part of confusion.

open( FH , "+<" , $file )
  or die "Unable to open '".$file."' - $!\n";
[download]

Btw. you really should use lexical variables instead of barewords for your filehandles. Especially if you use something obvious like 'FH'.

open( my $fh , "+<" , $file )
  or die "Unable to open '".$file."' - $!\n";
[download]

open my $fh, '+<', $file
  or die "Unable to open '$file': $!\n";
[download]

Using bareword symbols to refer to file handles is particularly evil because they are global, and you have no idea if that symbol already points to some other file handle. You can mitigate some of that risk by localizing the symbol first, but that's pretty ugly. Since Perl 5.6, you can use an undefined scalar variable as a lexical reference to an anonymous filehandle. Alternatively, see the IO::Handle or IO::File or FileHandle modules for an object-oriented approach.

Using bareword symbols to refer to file handles is particularly evil because they are global, and you have no idea if that symbol already points to some other file handle. You can mitigate some of that risk by localizing the symbol first

It isn't particularly hard to grep for "FH" being used elsewhere in the current package. And local doesn't actually mitigate that risk much unless you only use the file handle for the duration of some short-lived subroutine (and there are no subroutines in the original code).

Oh, and it was 5.6.1 where "open my $fh" became supported. :)

- tye        

*Erm* It's not about your package. It suffices if some library (which you may not even call directly) is using FH to read/write a file. Suddenly your file descriptor points to some totally different file/is closed/open for writing instead of reading or something completely different.

I'm sure I don't have enough time to debug something like this. Do you?