X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Eric Blake Subject: Re: [Spam?]Re: problem concating (>>) to a large file Date: Tue, 29 May 2007 15:28:49 +0000 (UTC) Lines: 20 Message-ID: References: <001201c79ea3$4d82bce0$8500a8c0 AT RUSNAK> <4656D47E DOT 5050906 AT byu DOT net> <001201c79f49$b57b3c90$8500a8c0 AT RUSNAK> <46582F2B DOT 2000300 AT byu DOT net> <000001c7a1d8$c2178e40$8500a8c0 AT RUSNAK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Eric Blake byu.net> writes: > Somehow, when the file size is huge, cygwin is not properly propogating that an > O_APPEND bit (0x9 in the flags printed from F_GETFL) means that the initial > offset of fd 1 is the end of the file. (And it would be nice if strace would > show the initial lseek offset of all inherited fd's when spawning a process). Actually, there is another cygwin bug. POSIX requires that this assertion succeed: assert (0 == lseek (open("existing", O_WRONLY | O_APPEND), 0, SEEK_CUR)); which is currently not the case on small files. The file position is only moved as part of the subsequent write()s. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/