🚀 go-pugleaf

"Hans Galema" <dontusethis@dontusethis.nl> wrote in message
news:3f8d9eca$1@newsgroups.borland.com...
>  > I was assuming that any kind
> > of file locking being done by the OS would have to be done with some
sort of
> > internal kernel object, which of course, no other machine would know
about.
>
> Heh, the other machine does not lock the file!

Well, now that is the real quesiton.  If an application on one computer
tries to lock a file on a shared network drive, who is responsible for
actually performing the lock?  The OS on the machine running the
application?  Or the OS on the machine where the shared network drive
exists?

> The other machine askes if
> the os will lock the file. There is only one os (on the machine with the
file)
> that decides. (Well if it is different, I'm wrong.).

Well, if Windows is smart enough to know that the file is on a shared
network drive and then ask the other machine for permission to lock the
file, then you would be right.

> >>Isn't appending to a file with fwrite() an atomic process ?
>
> > No, I don't think so, not even for multiple processes/threads on the
same
> > machine.
>
> But this even is simpler than many processes on one machine!
> There are not several threads running then. Only the os that
> has to handle requests. That is your server already.

Are you under the impressiong that I am running a client/server type
application?  I am not.  That was Remy's suggestion, and I was hoping for a
simpler solution; hence this question about shared network file locking.

> >>Every client could open the file once for a whole session.
> >>You do not have to lock. After fwrite() you could flush.
> >
> > I would be very suspicous of code that did that.
>
> It would help the discussion if you told why.

Because I am not sure there is anything to prevent multiple writes to a
shared file from occuring at the same time from different machines.

- Dennis