Front page | perl.perl5.porters |
Postings from March 2014
Christian Walde wrote: > On Wed, 19 Mar 2014 11:42:43 +0100, Nicholas Clark <nick@ccl4.org> wrote: >> On Wed, Mar 19, 2014 at 11:37:35AM +0100, Christian Walde wrote: >>> On Wed, 19 Mar 2014 10:30:57 +0100, Nicholas Clark <nick@ccl4.org> >>> wrote: >>>> On Wed, Mar 19, 2014 at 12:50:00AM -0500, George Greer wrote: >>>> >>>>> [default] -DDEBUGGING -Duseithreads >>>>> ../cpan/Win32API-File/t/file.t..............................FAILED >>>>> Non-zero exit status: 13 >>>>> Bad plan. You planned 270 tests but ran 1. >>>> >>>> That's really strange. 3 out of 4 pass. The other failed like this: >>>> >>>> Could not rmdir W32ApiF.tmp: Permission denied at t/file.t line 57. >>> >>> That looks like a timing issue. Adding `select undef, undef, undef, >>> 0.25;` >>> before the rmdir in question should fix that. >> >> Thanks for the feedback. I'm curious why. The relevant code is: [...] >> >> That code is single-threaded in Perl, isn't it? So what might be holding >> "open" the directory, but lets it go within 0.25s. > > It's probably the glob read. > > I'm not an expert on the underlying code, so the following is something > i explained to Tux at the QA hackathon based on my observations and > understanding of Microsoft and Windows: > > Windows is a User OS, as opposed to the Server OS which is *nix. > > Microsoft thus gets a lot of really fucking dumb feedback from users, > among which they probably got feedback like "doing things with files is > slow". > > So Microsoft probably implemented a number of file operations in the > manner that, to improve the user perception of operation speed, some of > them return as soon as the Windows kernel determines that it can > complete the operation, regardless of actual completion status. > > Supporting observation of this is that sometimes, with particularly big > files on my SSD, a delete will be acknowledged, but even after multiple > queries to the directory the file is still listed. Yet more attempts to > delete it get the answer of "This file does not exist anymore." > > The same thing likely happens with smaller files, but on such a > temporally microscopic scale that a quarter-second wait is plenty. > http://msdn.microsoft.com/en-us/library/windows/desktop/aa363915%28v=vs.85%29.aspx --------------------------------------------------------------------- The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. --------------------------------------------------------------------- Win32 files are Reference Counted.®¹ When the last kernel handle is closed, then the delete function is called in the FS driver. REFERENCE COUNTED is a registered trademark of Commercial Computing Camel Corporation. Commercial Computing Camel Corporation © 2014 All Rights Reserved.