[
https://issues.apache.org/jira/browse/JCR-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889795#action_12889795
]
Ulrich Cech commented on JCR-2677:
----------------------------------
That's right, we have to implement some more "checks", that the target-file is
correctly transferred from the temp-directory.
But actually, there is also a potential problem when relying on the renameTo()
method, because this method is not really atomic.
I think we can go like this:
1. The temporary file is written to a temp-directory (could be customized
somewhere and/or use some default directory)
2. The temp file is moved to the permanent target directory
3. checks are made to be sure the file is moved correctly
4. remove the "setLastModified()", this would also fail on WORM media
5. following the actual existent code...
I think when this method (addRecord() from FileDataStore) returns, the record
is unavailable to other "processes", so we do not need to handle the cases
mentioned with special effort. Or do I oversee side effects here?
> Extend the FileDataStore implementation to support read-only media (eg. WORMs)
> ------------------------------------------------------------------------------
>
> Key: JCR-2677
> URL: https://issues.apache.org/jira/browse/JCR-2677
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.2.0
> Reporter: Ulrich Cech
>
> Actually, the FileDataStore does not support read-only media. In a
> professional environment, where data consistence and unchangable of data is
> important (like archiving systems) this functionality is very important.
> I would try to do the implementation and contribute it...
> I attachted the conversation of the jackrabbit users mailinglist:
> -----Ursprüngliche Nachricht-----
> Von: Thomas Müller [mailto:[email protected]]
> Gesendet: Mittwoch, 14. Juli 2010 11:52
> An: [email protected]
> Betreff: Re: Jackrabbit and WORM
> Hi,
> > written to read-only media
> Do you mean written to write-only media? The DataStore implementation
> does not support this feature currently, however you could probably
> change the FileDataStore to support it. Instead of writing the
> temporary file to the datastore directory, it would have to be written
> to a different place (the temp directory for example). If you don't
> have a temp directory then it's a bit more complicated (binaries would
> need to be split into smaller blocks that fit in memory).
> Regards,
> Thomas
> On Wed, Jul 14, 2010 at 11:42 AM, Cech. Ulrich <[email protected]> wrote:
> > I have problems using JackRabbit with a storage-system, where files could
> > only be added, but not changed or deleted.
> > I found out, that in BinaryImpl.class there is created a
> > TransientFileFactory, where the stream is written in a temporary file and
> > later be deleted. If this deletion fails, I get an exception
> > ...
> > Caused by: java.io.IOException: Can not rename
> > c:\temp\cr20fs\repository\datastore\tmp21866.tmp to
> > c:\temp\cr20fs\repository\datastore\8d\54\82\8d548201d39d7594d182c2a3901fa38dfeebc6b3
> > (media read only?)
> > ...
> >
> > I tried to set the DataStore parameter "minRecordLength" to a very high
> > value, so that the stream is handled in memory, but this is limited to the
> > available heap space and so not applicable.
> >
> > Has anyone some experiences with Jackrabbit and read-only media? Can it be
> > configured, that only the repository and the versions are written to
> > read-only media, but other files (like the Lucene index, which could be
> > well configured to some other directory, so that's no problem) is written
> > to some "normal" storage system?
> >
> > Many thanks in advance,
> > Ulrich
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
