WinAdmin needs help w/ File System STDERR and

ReturnOfTheYeti has asked for the wisdom of the Perl Monks concerning the following question:

All, I am Windows SysAdmin with Zero knowledge of Perl. It has fallen into my lap to fix a script that worked on Server 2003, that no longer works "properly" in 2008 R2.

This is ActivePerl 5.16.3 Build 1603 (64-bit).

The issue is where it attempt to modify a log file. Here is the output:

Tue Jul 23 09:46:43 2013 (1374598003): THREAD-0: ERROR: Cannot rotate log file C:\faa\logs to path C:\faa\logs\QA-ENC04A_flashEnc.20130723094643.log: error code=Permission denied Failed in opening log file C:\faa\logs - using STDERR

The path is correct, and the logged in user has permissions to the file system, so I am not sure why I am getting the error.

Here is the code from the sript:

    # Rotate old log file.
    rotateLogFile();

    if ($configOptions{'logFilePath'}) {
        $LOG_FILE_PATH = $configOptions{'logFilePath'};
    }

    if (!isLocalLoggingEnabled() && !$DEBUGMODE) {
        print "NOTE: Local logging disabled in script configuration fi
+le\n";
    }

    # Make sure we can log to a log file, if necessary.
    if ($LOG_FILE_PATH) {
        my $logFileHandle = getLogFileHandle(1);
        closeLogFileHandle($logFileHandle);
    }

sub getLogFileHandle {

    my $logErrors = shift;

    # If no log file, use STDERR
    if (!$LOG_FILE_PATH) {
        return \*STDERR;
    }

    my $logFileHandle = IO::File->new(">>$LOG_FILE_PATH");

    if (!(defined $logFileHandle)) {
        $logFileHandle = \*STDERR;
        if ($logErrors) {
            print STDERR "Failed in opening log file $LOG_FILE_PATH - 
+using STDERR\n";
        }
    }

    autoflush $logFileHandle 1;

    return $logFileHandle;
}
[download]

Any wisdom you can provide me with would be greatly appriciated.

Comment on WinAdmin needs help w/ File System STDERR and Download Code

Replies are listed 'Best First'.
Re: WinAdmin needs help w/ File System STDERR and by Old_Gray_Bear (Bishop) on Jul 23, 2013 at 17:52 UTC
If indeed the only change is the OS, then I see a couple of places to go look: You no longer have the proper permissions to write the new log file (which, in fact is what your error messages says!) Some Process has the log open and has not been properly fitted out with 'close and re-open on my signal' logic. This being Windows, trying to read a file that someone else has open for writing can be problematic (see the previous bullets) Your old system was taking advantage of a 'Windows Quirk' (I have been told to stop calling them (adjective) Windows Bugs). That 'quirk' has been patched in the new OS. And, the ever popular solution -- "Murphy hates you" If it was me, I'd start with the Permissions issue first. Good luck, this is likely not to be the first 'OS quirk' issue you are going to run into. (Ask me sometime why I hate upgrading Operating Systems. Preferably sometime when we both have a stein of beer at hand and the night is young....) ---- I Go Back to Sleep, Now. OGB	[reply]
Re^2: WinAdmin needs help w/ File System STDERR and by ReturnOfTheYeti (Initiate) on Jul 23, 2013 at 18:36 UTC
Can you expand on: "Your old system was taking advantage of a 'Windows Quirk' (I have been told to stop calling them (adjective) Windows Bugs). That 'quirk' has been patched in the new OS. "? I am logged in as USER. I have given USER permission to the directory / file. USER can create/modify/delete files in the directory without issue. USER double clicks on the Perl script and that output is the error. The file the script is writing to is not in use. No other process has it open. So while I believe its a permission error, I am not sure where to look Thanks everyone for the quick reply	[reply]
Re: WinAdmin needs help w/ File System STDERR and by Loops (Curate) on Jul 23, 2013 at 17:30 UTC
Since the script once worked and hasn't changed, looking to the operating environment for a problem will probably be more fruitful. It sounds like you've upgraded to a new version of the operating system and something is configured in a slightly different way. Perhaps there is now a long running process that has the log file in question locked so no other process, such as this perl script, may operate on it. Check out : Rename unreliable on Windows	[reply]