Hi, Please see this thread to get a complete description of the problem - http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/074e0e8d-bbaf-4985-be8c-8e1da3cf13bc
I like to get opinion from perl folks about questions raised in the msdn thread. If I need to mail the author of win32.c, please let me know. -Karthik On Fri, Nov 4, 2011 at 3:23 PM, Karthik Rajagopalan <karthik.rajagopa...@schrodinger.com> wrote: > Hi, > > I am seeing a strange problem in my project where perl could not see a > file though it is present in the disk. We run a series of short > backend jobs ( each spanning 10 s ) through perl. The backend job > write an output file and exit, later which perl process would try to > transfer it. The perl process is threaded where master thread acts as > listener waiting for connection/messages and send file list to child > thread ( by checking for file existence ) about what files to > transfer. And child thread does the actual file transfer. > > The job runs fine initially and all of a sudden master thread fail to > detect file written by the backend. Debugging perl code ( 5.10.1 from > http://www.cpan.org/src/ - ASPerl ), I found stati64 of CRT fail and > return -1. On retry, the call seem to work fine. I can guarantee there > there is no race condition involved by backend process as we try to > access the file in perl only after backend exit. I also tried to > capture the events using ProcMon enabling 'File System Activity' and > made sure there are no external process accessing the file. When the > failure happens with stati64, I see the following events in procmon - > > <Time of Day> <Process Name> <PID> <TID> <Operation> <Path> <Result> > <Detail> <Description> > > 5:20:59.5315529 PM > perl.exe 3444 > 3496 CreateFile > D:\scr\rajagopa\test_31\test_31.01.mae SUCCESS Desired Access: Read > Attributes, Synchronize, Disposition: Open, Options: Synchronous IO > Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: None, > AllocationSize: n/a, OpenResult: Opened > n/a NYC\rajagopa > > 5:20:59.5315965 PM > perl.exe 3444 > 1636 DeviceIoControl > D:\scr\rajagopa\test_31\nyc-bld-w06-0-4eb305ae > INVALID PARAMETER Control: 0x12043 (Device:0x1 Function:2064 Method: 3) > n/a NYC\rajagopa > > 5:20:59.5316010 PM > perl.exe 3444 > 3496 QueryInformationVolume > D:\scr\rajagopa\test_31\test_31.01.mae SUCCESS VolumeCreationTime: > 1/20/2011 7:34:15 PM, VolumeSerialNumber: 188D-F175, SupportsObjects: > True, VolumeLabel: scr > n/a NYC\rajagopa > > 5:20:59.5316301 PM > perl.exe 3444 > 3496 QueryAllInformationFile > D:\scr\rajagopa\test_31\test_31.01.mae BUFFER OVERFLOW CreationTime: > 11/3/2011 5:20:47 PM, LastAccessTime: 11/3/2011 5:20:47 PM, > LastWriteTime: 11/3/2011 5:20:47 PM, ChangeTime: 11/3/2011 5:20:47 PM, > FileAttributes: A, AllocationSize: 128, EndOfFile: 126, NumberOfLinks: > 1, DeletePending: False, Directory: False, IndexNumber: > 0x8e00000002f208, EaSize: 0, Access: Read Attributes, Synchronize, > Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: > Word > n/a NYC\rajagopa > > 5:20:59.5316368 PM > perl.exe 3444 > 1636 DeviceIoControl > D:\scr\rajagopa\test_31\nyc-bld-w06-0-4eb305ae > INVALID PARAMETER Control: 0x12043 (Device:0x1 Function:2064 Method: 3) > n/a NYC\rajagopa > > 5:20:59.5316622 PM > perl.exe 3444 > 3496 CloseFile > D:\scr\rajagopa\test_31\test_31.01.mae SUCCESS n/a NYC\rajagopa > > Has anyone faced a similar situation with windows perl? > > As you can see, the set of file operations involved with > "test_31.01.mae" using stati64 is shown as SUCCESS. But the result of > stati64(..) is -1 and GetLastError(..) give 6. Why would this be? Is > procmon showing wrong status? Is stati64 buggy in threaded > environment? Is it safe to retry the stati64 call if return value is > -1 and GetLastError() is 6? > Please throw pointers as this issue is important to fix soon. > > -Karthik > _______________________________________________ ActivePerl mailing list ActivePerl@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
