Dear Garret,
> We bought Sharity 1.06 running on a Solaris 2.6 machine, and it
> has worked well for us.
Just a note: You bought a license which is valid for Sharity 1.x and will be
valid for Sharity 2.x, not just 1.06. I'm mentioning this because there have
been some misunderstandings recently.
> I have a question about file locking: I understand from the manual
> that Sharity does not support file locks, but are there any
> suggested workarounds ?
No there are no workarounds. If you describe what you want to accomplish,
maybe there's a way to do it without file locking.
> Will an open() and read() fail if the file is still open on the NT
> side ?
It depends. On the NT side, all processes can use all kinds of locking. If
the file is just open, there's no problem to read and write it from Unix. If
the file is locked, however, the "locked" operation will fail. Unfortunately,
many applications on Windows lock files for read and write although it would
not be necessary.
> I have seen errors returned from unlink() commands, while the remote
> file is being written on the NT server.
NT does not allow deleting files which are used and maybe locked by other
applications. If the file is open by Sharity (even on an other client), the
file is closed before the unlink is attempted. Files used by Sharity are
therefore not a problem during deleting. If a file is locked on the server
(or a Windows client), there's nothing Sharity (or any other client) can do.
> If a file on an NT server is open for writing by a process on the
> NT server, exactly which operations are allowed and which forbidden
> ?
It depends on how the file was opened on the server. If it's open in "shared
mode" (no locks), Sharity can read and write the file. It can probably not
rename or unlink it, but I'd have to test this to be sure. If the file is
locked for writing, Sharity can still read but not write. If it's locked for
read and write, Sharity can do nothing.
You should also know that Sharity attempts to be as neutral as possible with
respect to file opens and locks. This means that a file, which is open on
the Sharity client, can later be locked by NT. The client, which could
successfully open the file, is then unable to read or write, depending on the
lock set by NT. The server is thus able to "steal" files from Sharity.
There's no way to change this behaviour, except switching Sharity's frontend
(the module which maps the files into the filesystem) from NFS2 to a direct
kernel interface. Even NFS3 would not help.
Regards, Christian.
--
Dipl.-Ing. Christian Starkjohann
Objective Development
mailto:[EMAIL PROTECTED] | http://www.obdev.at/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To unsubscribe send a mail with the words "unsubscribe sharity-talk" in the
body to <[EMAIL PROTECTED]>. If you want to reach a human, please write to
<[EMAIL PROTECTED]>.
