Expected behavior?

[Juan Piernas Canovas]

Hi all,

Taking up this email that I sent almost two months ago, I have found out 
that there is a "bug" in my code. The bug is that I use "w+" to write to 
the second file (which is the output file of my program). Since "w+" 
(and "w") truncates the file, if several processes open the file at the 
same time, a process can delete the information previously written by 
another process. I tried several open modes without success, and I 
probably left that option without noticing.

But, and here is the funny part, if I want the program to work properly, 
the output file must exist and must be opened with "r+". This is 
counterintuitive because I just want to write to the file, I do not want 
to read it. As I have said, "w" and "w+" truncate the file and they are 
not valid options for my program. But "a" and "a+" are not valid options 
either. The problem is now that "fseek" does not work with these "fopen" 
modes. How is it supposed that I must know that? I have not seen any 
information about this problem either in the manual pages or info 
entries of fseek and fopen. Moreover, fseek does not fail and returns 0. 
I know that, with "a" and "a+", output is written at the end of the file 
but, frankly, I assumed that this was the default behavior that you 
could change with fseek. Obviously, I was wrong.

I think that a clarification about this issue in the documentation of 
fseek would be appreciated.

Regards,

    Juan.

Juan Piernas Canovas wrote:
> Hi all,
>
> Before submitting a bug, I would like to know if the following is an 
> expected behavior. I have written a small program (attached) which 
> basically multiplies a set of doubles stored in an input file by a 
> scalar, and saves the resulting doubles in an output file. As 
> arguments, the user has to specify an offset and a size. The offset is 
> the starting point in both the input and output files, and the size 
> says how many bytes to read from the input file, and write to the 
> output file. Obviously, if the output file is empty and the offset is 
> not equal 0, we will be creating a sparse file.
>
> I have also attached a script which runs the program twice by creating 
> two processes at the same time. Both processes use the same input and 
> output files, and receive the same scalar and size values, but 
> different offsets. With the give parameters, the processes read and 
> write different "disjoint" portions of the input and output files. 
> Note that the output file will be a sparse one because the processes 
> leave "holes" in the file. The script also checks whether the content 
> of the output file is correct or not.
>
> The problem that I'm having is that the output file is not created 
> correctly, and I am pretty sure that the problem is in the fwrite 
> function. The first doubles (in an indefinite amount) written by 
> sometimes the first process, sometimes the second, and sometimes both 
> processes, are always 0.0, what seems to mean that there is a hole 
> where there should not be. That occurs randomly.
>
> Please, note that we are talking about independent processes which 
> must not share any information about the file (such as the file pointer).
>
> Does anyone have any clue about what is happening?
>
> BTW, I do not have any problem if I use the "low-level" open, read, 
> write and close functions. And I have got the problem in three 
> different Linux distributions (SLES 10.2-sp1, RHEL 4, Fedora Core 6) 
> with different glibc versions.
>
> Thanks in advance,
>
>    Juan.
>
> PS. I can send the input file if needed, but it does not contains 
> anything special, just random numbers.