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

I'm trying to read a growing file with the following code: 
use IO::Handle;
$file = $ARGV[0];
open(INFILE,"< $file");
while(1)
{
  while(<INFILE>)
  {
    print("$_");
    sleep(5);
  }
  INFILE->clearerr(); 
}

[download]
In order to test it, I've been doing an echo abc >> test.log from the dos prompt on NT. This works just fine and my script prints out the new line with "abc" on it.

When I open notepad, wordpad or gvim and try to write to the file, it fails and says the file is in use by another process.

Any ideas why it would be locked for writes when I opened it in read only mode?

This is my first post so don't hurt me!!! :)

Thanks...

Replies are listed 'Best First'.
(tye)Re: Unable to write to a file opened in read only mode
by tye (Sage) on Nov 03, 2001 at 12:11 UTC

    Okay, I finally got a chance to test this under WinNT... and I got the same results I got under Win2K. With a file open for read-only access in Perl, notepad and gvim don't care in the least and will still open, edit, and save the file.

    It is nice that several people have chimed in with how "this is just how Windows works", but I don't believe any of them. (: I've certainly seen cases where shared access was denied when I had hoped that it wouldn't be, but a quick test shows that this isn't such a case.

    It is true that, unlike Unix, Windows gives you the option of requesting that no other program do certain things to the file while you are using it and of having that request enforced by the operating system (not requiring all tasks dealing with the file to cooperate nor requiring special tagging of the file to get this).

    It is also true that many Windows programs, especially those not written in C, chose to request no sharing when they open files (or at least less sharing than you sometimes would like).

    The details are that you can request three types of sharing: read, write, and delete. ("Delete" sharing doesn't apply prior to WinNT.) You specify zero or more of these types of sharing be allowed whenever you open a file in Windows. When using C code, the default is to request only "read" and "write" sharing.

    If you don't request "read" sharing, then you won't be able to open the file if anyone else has the file open for reading and once you have the file open, nobody else will be allowed to open it for reading. "write" sharing is exactly the same except you replace "reading" with "writing".

    See Win32API::File for some more information on this and how to use Perl to play with opening files specifying different types of sharing.

            - tye (but my friends call me "Tye")
[reply]
      Thanks for taking the effort to try it. My version of notepad and gvim must be using the "no sharing" option. I have tried it on nt workstation and server with the same locking problems. I'm not sure how it is working for you.

      If I understand you correctly, your saying it depends on how the application is opening the file for writes. This will determine if it can write to the file or not. So...If the app writing to a log file doesn't allow anyone to be reading the file, I'm out of luck right?

      It sounds like the solution might be for me to not open the file at all. I guess I can create a temp file and save my last position read each time I create and read the temp file. Based on the position, I can read only the new lines that have been added.

      I think this will work, but it is not as clean as the original solution.

      Thanks.

[reply]
Re: Unable to write to a file opened in read only mode
by Ven'Tatsu (Deacon) on Nov 03, 2001 at 04:48 UTC
    Any ideas why it would be locked for writes when I opened it in read only mode?

    Because that is how file locking should work. You can allow many programs to read from a file at once, but if a program is writing to a file nothing else should read from or write to it. If you let a file be read by a program while it's being writen two by another program the file may change between one read and the next. That can cause trouble.
[reply]
      I strongly disagree that this is how file locking should work. It is how it does work on Windows, but it is not how it works on Unix. The result is that you have an additional piece of complexity on Unix that applications need to be aware of, but when you are dealing with shared resources, the Windows behaviour is (in my experience) far harder to administer.

      Furthermore it can be very convenient. For instance as a debugging aid it can be very nice to type in: 

      tail -f /var/log/apache/error.log

      [download]
      and watch the result of writes made by Apache to its error log in real time as you are interacting with the browser. (Writes which you get in there with well-placed warn statements...) This works just fine on Unix. But Windows makes it far too easily for an application to make this kind of interaction impossible. :-(
[reply]
[d/l]
        Actually I have a zip of Unix tools that were ported to windows, Unfortunately it is on my work computer and I don't remember the site I downloaded them from. I will update this with a link ASAP. However it becomes as easy as using the tail command. I am not sure if this will work for you but it is a good source for those of us who only have Windows to see the world.
[reply]
        It was my understanding that both Unix and Windows used advisory locking, and had the same basic set up of read locks and write locks.
        The only big diffrence that I know of (besides some file systems locking issues) is that most programs writen for windows obey the advisory locks. When Word decliens to open a file that is in use notepad will open it without trouble (unless it's to big).

        Besides the argument that Windows might make it easyer to obey or harder to ignore file locks I don't really see where the diffrence is. You can still ignore them if you desire to.
[reply]
Re: Unable to write to a file opened in read only mode
by Fastolfe (Vicar) on Nov 03, 2001 at 05:43 UTC
    This is just how NT is, in my experience. Try running your script on a non-Windows OS (UNIX) and see if the behavior is more to your liking.
[reply]

Back to Seekers of Perl Wisdom