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
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 seems to work just fine on unix. Unfortunately, there are some issues with using the tail command on NT or unix. Under some circumstances, there is the potential to miss some of the lines being written to the file.
Thanks.
| [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] |