Commit 72ebc592 authored by Paal Kvamme's avatar Paal Kvamme
Browse files

User opt-in for the readonly kludge. Update documentation.

parent 540bde34
......@@ -900,26 +900,52 @@ limitations under the License.
</ul>
<h4>Current implementation</h4>
<p>
All files created by or updated by OpenZGY will be marked
read-only on close.
</p>
<p>
Opening a file for update in OpenZGY will cause the read-only
mode to be removed, then put back when the file is again closed.
This is not how it is meant to work. But it is the best I can do
in the short term.
</p>
<p>
OpenZGY might later leave it to the application that writes the
file using OpenZGY will decide whether to mark the file
read-only or not. And then don't reset the flag. It is not clear
whether all applications can handle this.
Three additional settings have been added to the IOContext.
</p>
<dl>
<dt>setRoAfterWrite(bool)</dt>
<dd>
<p>
Set the ZGY file to read-only when done writing it. Has no
effect on files opened for read. Defaults to on. Most
applications will want to turn in this on because most
applications do not expect to update ZGY files in place.
</p>
</dd>
<dt>forceRoBeforeRead(bool)</dt>
<dd>
<p>
Sneak past the mandatory locking in SDAPI by forcing the
read-only flag to true on the ZGY file, if needed, on each
open for read. This allows for less overhead, more caching,
and use of the altUrl feature. This option is useful if the
file is logically immutable but was not flagged as such.
E.g. the creator forgot to call setRoCloseWrite(true), or
the ZGY file was not created by OpenZGY. The option has no
effect on files opened for create or update. Caveat:
Allowing a read-only open to have a permanent effect of the
file being opened is not ideal.
</p>
</dd>
<dt>forceRwBeforeWrite</dt>
<dd>
<p>
Dangerous option. Sneak past the mandatory locking in SDAPI
by forcing the read-only flag to false on the ZGY file, if
needed, that is about to be opened for update. The
application must know that the file is not open for read by
somebody else. There is also a risk that data might exists
in cache even for a closed file. The application assumes all
responsibility.
</p>
</dd>
</dl>
<p>
Files created by the old ZGY-Cloud library will still be left
writable. This means that altUrl will not work for those.
Hopefully applications will move away from the deprecated
ZGY-Cloud fast enough that this will not become a problem.
writable. This means that altUrl will not work for those, unless
forceRoBeforeRead is in effect. Hopefully applications will move
away from the deprecated ZGY-Cloud fast enough that this will
not become a problem.
</p>
</body>
</html>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment