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.