Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <4203B6B0.70000@x-ray.at>
Date: Fri, 04 Feb 2005 18:53:52 +0100
From: Reini Urban <rurban AT x-ray DOT at>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: Mark Paulus <mark DOT paulus AT mci DOT com>
CC: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: FindNextFileA (fhandler_disk_file::readdir) Bizareness under NTFS - Resolved
References: <0IBC002HSFBWL8 AT pmismtp01 DOT mcilink DOT com>
In-Reply-To: <0IBC002HSFBWL8@pmismtp01.mcilink.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

Mark Paulus schrieb:
> I finally got enough time to track down this issue, and
> it comes down to a perl issue.  Seems that a perl script is
> creating the file, but it isn't doing a close on the file, so it's
> making the file hang around a bit too long (like maybe
> it's a race condition of NTFS).
> 
> Anyway, I patched the perl script with an appropriate close (IN....)
> statement, and the issue/bizareness goes away.

But the race can only happen inside the perl script. Right?
perl implicitly closes all open files when the script exits.
(as well as it ideally should release all its memory, sigh)

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

--
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/