> ... selects a list of the really old [files] that are going
> to be compressed to save space. ... the filename is the same
> whether the file is compressed or not. So the client app can
> only look @ the 'archived' boolean to judge if it needs to
> decompress the file.
There's your mistake. If you can change this one behavior, your
problem goes away. Hopefully, you have a single function somewhere
that your clients all use to access the file. In that case, you
can:
* Always store the "uncompressed" name in the table.
* A client first looks under the "uncompressed" name,
then under the "compressed" name (which has an
extra/different extension, etc.)
When you compress, you compress from the old name to the new name.
As long as the old version is still there, clients will use it,
so there's no chance of someone trying to read the
incompletely-compressed
file. The nice thing about this strategy is that it's fairly
straightforward to change from your old system to this, at the
cost of a temporary increase in disk space.
If using two filenames is not possible for some reason, you might
try adding logic to the client to test the initial bytes of the
file to see if it's compressed or not. Assuming you're on Unix,
you can compress to a new file, then rename the compressed
file to the old filename, and it should work correctly.
If this message table is really as heavily used as you say,
a strategy that lets you avoid locking entirely seems worth
pursuing.
- Tim
