This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reliable old script loses data on new Cygwin installation

Thomas Baker wrote:

> 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).
René Berber

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]