File handle question

[Cyri]

Looking for some clarification on something. I'm trying to monitor a log file and want to know if the following code is valid to go back to the previous line in a file? Can I have more than one file handle open to the same file?

$file = FileOpen($sLogFile, 0)
;Loop to check file
While 1
    $file_temp = $file
    $line = FileReadLine($file)
    If @error <> -1 Then
        $file_temp = ""
        ;do stuff here to validate readline
    Else
        $file = $file_temp ;Set file object back to previous line
        ExitLoop
    EndIf
Wend

I may not even be doing this the correct way to begin with. The code above doesn't show the big picture, but I'm trying to avoid having to do a FileOpen every time I want to validate new entries in the log file. The log file gets really big and I don't want the performance hit of having to read through all the lines I've already gone over. I suppose I could keep a line count reference so the FileReadLine() can pick up where I last left off. Is that the best way?

Edited February 17, 2010 by Cyri

[jchd]

Lookup FileGetPos and FileSetPos in the help file, along with the example. In your code $file and $file_temp are identical and contain a handle, (as the doc says!). This handle is to be used to indicate on which file subsequent file operations must apply. Assigning "" to a handle doesn't make sense.

If there is another process writing to this log file, then you should probably open it (for reading) set your last known position with FileSetPos, read from there to EOF, record the new position with FileGetPos, close the file and then enter a loop only to process the data just read. This will minimize locking issues, but may not remove them completely, depending on the file lock type used.

Don't try to FileReadline with a line number, it would be utterly inefficient (and pointless).

[Cyri]

My bad...I just checked my version of AutoIt on my home computer and didn't realize I was running a really old version 3.3.0.0 from 2008 which doesn't have either of those functions. Ouch! I'll try the commands you suggested in the latest version. If I'm still having troubles I'll get back to you.

[jchd]

Remember: first thing to do before morning coffee is to check for software updates and AutoIt is no exception

To be honest, that's not all truth: I wish I didn't apply KB977165 from last Windows update on this particular XP box as it now take 25 minutes to boot.

[Cyri]

I was confused at first by FileRead. The documentation says it defaults to reading the entire file but doesn't mention anything about only reading from the set position in the file. Even though the examples from those two commands you provided clearly show it. Based on that verification I think this is going to work out well. Thanks for your help.

[jchd]

Re-read the doc!

Beware that FileRead will read the whole file if no [byte or character] count is given. If you give it a count, then it must read from current file position! It can't just read at random, hopefully.

FileReadLine will read the line at current file position if no line number is given, or the specified line if a line number N is passed (but that means to parse N-1 line one by one, a slooww process to be avoided like the plague).

[whim]

@jchd

To be honest, that's not all truth: I wish I didn't apply KB977165 from last Windows update on this particular XP box as it now take 25 minutes to boot.

You might well already know this, but just in case ...

wsus offline update

whim

[Cyri]

Re-read the doc!

Beware that FileRead will read the whole file if no [byte or character] count is given. If you give it a count, then it must read from current file position! It can't just read at random, hopefully.

FileReadLine will read the line at current file position if no line number is given, or the specified line if a line number N is passed (but that means to parse N-1 line one by one, a slooww process to be avoided like the plague).

Sorry, still confused. The example shown for FileGetPos() and FileSetPos() has FileRead($hFile) with no additional param other than the file handle yet it only returns data after the current position in the file. So is it still reading the entire file (because no byte or character count was given) and only returning the data after the set position?

[jchd]

Apologies, you're right that the doc is a bit imprecise. It should more clearly state that FileRead will read from the current file position up to either <count> number of by bytes/characters or up to EOF if <count> is omitted.

FileRead without count is mostly used to load a file as a block from the start and that's probably why the fuzzy wording.

[Cyri]

Since upgrading to v3.3.4.0 my FileOpen (read mode) no longer works when the app that writes the log is running. I get a -1 return code. However, if I downgrade back to v3.3.0.0 the FileOpen (read mode) is able to read the log file with no issues. Anyone know if something changed between those versions with FileOpen?

Edited February 19, 2010 by Cyri

[jchd]

This is the matter of ticket #1413, which also relate to ticket #546.

What changes here is that the file is here opened by an external application which clearly didn't choose to acquire an exclusive lock on it, allowing it to be read at the same time as you do with your v3.3.0 script. This clear example shows that the read opening mode indeed changed and is no more compatible with previous versions.

You should perhaps reply to ticket #1413 insisting that in your case the file is being writen by another program, but that post 3.3.2.0 versions don't allow to read it like it was possible with previous releases. You have the example at hand, so it's easier for you to document what happens exactly. Be sure to read and understand ticket posting guideline, though!