X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 12 Mar 2010 14:19:30 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: redirect-append (>>) creates garbage-y file Message-ID: <20100312131930.GO6505@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <4B30AD0BED19E842AAE88DC397364931240B83C3E9 AT mail3 DOT walsh DOT edu> <4B9A3C12 DOT 3030604 AT alum DOT mit DOT edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9A3C12.3030604@alum.mit.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Mar 12 08:05, Bill Lebow wrote: > Corinna Vinschen wrote: > > > On Mar 11 13:12, William Lebow wrote: > > > echo foo | tee -a test3.txt : terminal output is okay but test3.text > > > starts with 3 characters of garbage before the string foo > > > > > > echo foo | tee test4.txt : terminal output is okay and test4.txt > is okay too > > > > > > So "tee -a" has the same issue as ">>" when creating a new file. > > > > > > BTW, I believe that the garbage characters that precede the text > is an encrypted > > > version of the text in the file. This Credant software is > protecting my txt files > > > by encrypting them. > > > And it's doing something blatantly wrong. Quite obviously, Cygwin > > only writes the data once. If it's in the file twice, once encrypted > > and once unencrypted, then this Credant software does not understand > > native NT writing with append mode(*). You should report this as a bug. > > > > Corinna > > Corinna, I can't argue with anything you say, and I have reported it > to the other > vendor. That said, this wasn't a problem with earlier versions of > cygwin so I thought > maybe there is something that can be done on the cygwin side. Sure, but in that case, no, there's nothing we can do about it, except to revert major functionality in Cygwin to the old implementation. However, since we're using an officially documented API, I don't see a reason to do that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple