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 [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
