X-Spam-Check-By: sourceware.org Message-ID: <46B0D18D.40409@tlinx.org> Date: Wed, 01 Aug 2007 11:31:41 -0700 From: Linda Walsh User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: unlink()'s not quite POSIX behavior. References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Joe Smith wrote: >> When the file's link count becomes 0 and no process has the file open, >> the space occupied by the file shall be freed and the file shall no >> longer > Could we at least simulate the behavior by moving the file out of the > way (simultaionsly renaming it to something unique), > and forcing it into the delqueue? (by Setting the > FILE_DISPOSITION_INFORMATION's DeleteFile flag to true?) > > Wait a moment, that looks to be exactly what unlink_nt is doing? > > (The problem is with a call in Python3k getting a "Permission denied" > (ERRNO 13) error when attempting to create a file shortly after it has > been deleted with unlink. That seems to be consistant with standard > windows behavior for deleting a file, as trying to create it again > before the last handle is closed would return an ERROR_ACCESS_DENIED.) > > However, it looks like with unlink_nt that should not be happening, right? > > Nevermind. I see that the relavent changes to NT_unlink are just very > recent, and the only problem is that the latest cygwin dll does not > incldue those changes yet.> ----- I seem to remember being told that changing the rename function to work in this, POSIX-compatible way, was impossible with cygwin's current fork implementation -- and that Cygwin would have to keep track of what files have been renamed (if any were DLL's) and propagate changes to child processes (after a fork call) so they could correctly pull in contents of "old, replaced DLL's". Is this change to fork something that is being worked on? I.e. will we be able (at an application (setup.exe or cygperl replacing DLL's) level) to rename "in-use" DLL's and copy in new versions? I thought Eric indicated that this tracking would make an already slow process even slower(?) and wasn't worth it. (http://sourceware.org/ml/cygwin/2006-12/msg00906.html) Has this changed? Or, more accurately, is this about to change? Was it decided to go with the (seemingly) POSIX correct action to allow the "rename-to-tmp+copy-in-new-DLL" (Rtt+CinD) to work? Will Cygwin be keeping track of the old "deleted" (but still in-use via a cygwin open Filehandle) libraries to duplicate into new children processes? I seemed to remember feeling my "hand slapped" at suggesting we use "Rtt+CinD" as it wouldn't be practical to implement. Maybe the open-handle->"deleted file" idea isn't that expensive to implement afterall? (Despite it being a RPITA; hail emperor bill). Linda -- 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/