X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: =?ISO-8859-1?Q?Ren=E9_Berber?= Subject: Re: Reliable old script loses data on new Cygwin installation Date: Mon, 12 Nov 2007 04:03:14 -0600 Lines: 55 Message-ID: References: <20071111173033 DOT GA2360 AT sub-tombaker> <20071112090628 DOT GA3792 AT sub-tombaker> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <20071112090628.GA3792@sub-tombaker> X-IsSubscribed: yes 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 Thomas Baker wrote: [snip] > However, the other problem (see below) has occurred -- > sporadically -- on three different machines, all running > German or English-language versions of XP, two with SATA > disks and one with an ATA disk, all with freshly downloaded > installations of cygwin.[snip] OK, that's interesting, 3 machines one using non SATA disk. Same irregular pattern of 10 to 20 runs without problem? > A colleague of mine suspects that the Korn shell script on > Cygwin is running so fast that occasionally the next command > is being executed before the buffer is written to disk. Is it > possible that the shell is somehow creating the file "german" > (above), with its file name and length, a split second before > the contents are written to disk, then the next command is > being run too quickly, the script gets tripped up but keeps > running, and data is lost? No. The actual storage of data is done by the operating system, not by Cygwin, the operating system provides the data even if it hasn't been stored on disk (it could still be in a memory buffer). > As this is happening both on a SATA disk and an ATA disk, I > can't help wondering whether cygwin is perhaps too efficient > for the faster hardware.[snip] > However, he says that this could conceivably solve the problem > for this script, but if the problem is that Cygwin is too fast > for the hardware I could still get this problem while using, > say, "mv". Can this explanation be ruled out? Move is different, it usually only renames the file, but does a copy if necessary. But again, it is the operating system the one that does the actual change, what any program does is usually to a buffer in memory which is marked to be stored by the operating system. The speed is not the problem, it could be the usual suspect: an anti-virus, unlikely because the data written is not executable but it could be adding an extraneous delay between data written and data read. The only solid evidence is the error message from Windows, and it says "device", that means that the hard disk is having problems (it could be the driver) but not your script or any program. Did you do anything special to the hard disks on all 3 machines? something like run an optimizer or tune parameters? The other problem could be related to the first, if the disk is "failing" then creating/moving a file will fail, I'm not sure if "permission denied" will be the error message but I could test that later (I can make my SATA disk fail using a program that allows the async unbuffered I/O). --=20 Ren=E9 Berber -- 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/