Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Message-ID: <4203B6B0.70000@x-ray.at> Date: Fri, 04 Feb 2005 18:53:52 +0100 From: Reini Urban 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 CC: "cygwin@cygwin.com" Subject: Re: FindNextFileA (fhandler_disk_file::readdir) Bizareness under NTFS - Resolved References: <0IBC002HSFBWL8@pmismtp01.mcilink.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/