o3find - Open Issues
Go
Back to o3find main page
Is the "Already open" feature really dangerous?
I don't think so, but I'd like someone to test it!
Technical explaination: o3find uses the ZipArchive library.
The ZipArchive library opens files with the "share deny write" option.
This means that it can read a file only if no-one is reading it, or if READERS
are reading it. Programs such as OpenOffice.org are WRITERS, not just readers.
If there's a writer, readers (and other writers) cannot access the file.
Thus, I changed the ZipArchive library (I can, because it's GNU GPL
just like o3find). Now the main function i use to open files (CZipArchive::Open)
has a boolean switch (bCanReadAlreadyOpenFile)
I can use to specify the exact open mode I want.
If you don't specify the switch, or if you set it to false,
ZipArchive will perform the usual open operation
with the standard "share deny write" option (CZipFile::shareDenyWrite).
But o3find sets bCanReadAlreadyOpenFile to true,
when the appropriate option is specified
(for example, the "-ao" in the command-line edition).
In this case, ZipArchive will use the CZipFile::shareDenyNone option
(see the internal function CZipStorage::OpenFile) in order to read even
locked files, i.e. files that are currently open by OpenOffice.org or other
programs.
Is it dangerous?
In my tests, everything went smoothly... but I never
used the "share deny none" option before
(It reminds me the NOLOCK table hint in T-SQL, if you understand what I'm
talking about... yes, colleagues say that the NOLOCK table hint is useful
and not harmful...).
I'm sure many programs use that options, because I can open a SXW file
currently open in OpenOffice.org with zip tools or even Notepad,
and even the ordinary Search feature in Microsoft Windows does not
distinguish between open and closed files.
On the contrary, other programs such as Microsoft Office can't open an
already open document, so I guess they use the "share deny write"
option instead of "share deny none".
What happens if the document is changed (e.g. saved by OpenOffice.org)
while o3find is reading it?
(And don't reply: I'm sure I'm NOT changing the document.
What about autosave? What about shared server directories and
multi-user environments?)
I don't know, but I think that errors are likely to occur.
Dangerous errors? Maybe I'm getting paranoid :-) Time will tell...
If you like, you can test this feature, and tell me if something bad occurs...
Well... of course, if you think my approach isn't correct,
let me know,
and I'll fix the program as soon as I can!
The Double Content Problem
An o3find user sent me a SXW file. He told me that o3find could not
find text in that file. I opened the file with a zip tool and found
out that there were two content.xml files inside (in two different
folders)
The OOo documentation does not talk about multiple content files
(or it does, and I didn't find the point!), so o3find reads
only the first content.xml file it finds in the document
(in the root of the ZIP archive).
Should o3find read ALL content.xml files that are inside the archive?
I'm not sure, so I ask your help... if you are more experienced
in SXW files, write me about this problem,
and I'll be glad to fix the program!
Go
Back to o3find main page
Copyright © 2003-2005 Paolo Copello.
Important note: The ad-banners were added by Tiscali hosting service, Paolo Copello
is NOT responsible for their contents
Nota importante: I banner pubblicitari sono stati aggiunti dall'hosting service di
Tiscali, Paolo Copello NON è responsabile dei loro contenuti.