[
https://issues.apache.org/jira/browse/JCR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643188#action_12643188
]
Peter Dettman commented on JCR-1838:
------------------------------------
Yes, a quite small repository (a few large items), and the streaming of data is
also slow.
It seems that FileDataStore relies on the tmp file being updated at least once
(at least one block is written?) b/w the GC calls to
updateModifiedDateOnAccess(..) and deleteAllOlderThan(..). If not, then the
lastModified() value on the tmpFile is "old", and it is deleted.
The attached patch fixes my immediate problems, but tmp files may then leak
under some circumstances. There is the option of simply using deleteOnExit() on
these files.
Alternatively, tmp files could be tracked by the 'inUse' map, or something
similar.
> Garbage collection deletes temporary files in FileDataStore
> -----------------------------------------------------------
>
> Key: JCR-1838
> URL: https://issues.apache.org/jira/browse/JCR-1838
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: core 1.4.6
> Environment: Solaris 10, JDK 1.6.0_03
> Reporter: Peter Dettman
> Priority: Minor
> Attachments: jcr1838.diff
>
>
> In FileDataStore.addRecord(InputStream), a temporary file is created. The
> data is written to the file and then it is moved to its final location (based
> on the contents hash).
> If the garbage collector runs whilst this temp file is present, it deletes it
> (on Solaris 10 at least), and the addRecord fails at the attempt to rename
> the now non-existent temp file.
> I am attaching a minimal patch that prevents these temp files being deleted
> by deleteOlderRecursive(..), regardless of their lastModified() value.
> I have made this a Minor priority, since there is the obvious workaround of
> disabling the GC.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
