Mail Archives: cygwin-developers/1998/02/19/10:05:38
In article <01BD3D21 DOT 973CA0F0 AT gater DOT krystalbank DOT msk DOT ru>,
Sergey Okhapkin <sos AT prospect DOT com DOT ru> wrote:
>Ian Lance Taylor wrote:
>> > I'm not sure. When O_APPEND is set, we have to seek to end of file
>on
>> > fdopen() call. When __SAPP is set, _every_ write call seeks to eof
>before
>> > write! Is it a correct behavior for O_APPEND? BTW, where fdflags
>variable
>> > is defined?
>>
>> That is correct for O_APPEND: every write should go to the end of the
>> file, wherever the end of the file happens to be at that time. For
>> example, on Unix this can be used for writing log files from several
>> processes; provided each write is done in a single call, if you use
>> O_APPEND then you know that none of the writes will clobber another.
>>
>> The patch looks OK to me.
>
>This behavior doesn't works with gnu CSSC. The code makes fdopen(fd,
>O_APPEND), writes some lines to the end of file, seeks to the beginning of
>file and writes new file header. With this patch new file header will be
>written to the end of file!
Maybe I'm unclear on what is happening here:
1) open("file", O_APPEND|O_WRONLY)
Every write should write to the end of the file regardless of
intervening lseeks.
2) fopen("file", "a")
Every write should write to the end of the file regardless of
intervening lseeks.
3) fd = open("file", O_WRONLY); fp = fdopen("file", "a");
Should the characteristics of 'fd' be changed that every write
goes to the end of the file? Or should there be a one time seek
to EOF.
I think "a" here should be identical to "a" in 2) above.
Apparently, glibc agrees:
/* The May 93 draft of P1003.4/D14.1 (redesignated as 1003.1b)
[System Application Program Interface (API) Amendment 1:
Realtime Extensions], Rationale B.8.3.3
Open a Stream on a File Descriptor says:
Although not explicitly required by POSIX.1, a good
implementation of append ("a") mode would cause the
O_APPEND flag to be set.
(Historical implementations [such as Solaris2] do a one-time
seek in fdopen.)
However, we do not turn O_APPEND off if the mode is "w" (even
though that would seem consistent) because that would be more
likely to break historical programs.
*/
So, glibc seems to do the same thing as what this patch
(if I understand it correctly) tries to do.
I don't know what CSSC is, but I'm surprised that a GNU program
would work this way given the behavior of glibc.
--
http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal
VMS=>UNIX Solutions Boston Business Computing the real can be."
- Raw text -