[
https://issues.apache.org/jira/browse/JCR-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved JCR-2674.
---------------------------------
Fix Version/s: 2.2.0
Resolution: Fixed
> FileDataStore ignores return code from setLastModified
> ------------------------------------------------------
>
> Key: JCR-2674
> URL: https://issues.apache.org/jira/browse/JCR-2674
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-core
> Affects Versions: 2.1.0
> Environment: Solaris/ZFS/JDK1.6.0_20
> Reporter: Peter Dettman
> Assignee: Thomas Mueller
> Priority: Critical
> Fix For: 2.2.0
>
> Attachments: JCR-2674.patch
>
>
> Garbage collection depends on the file modification date being successfully
> updated when records are "touched" during the mark phase. The result of a
> silent failure is the catastrophic loss of the file in the sweep phase.
> FileDataStore.getRecordIfStored does not, however, check the return code from
> setLastModified.
> I believe I was bitten by this when my dev deployment ran out of disk space.
> A substantial portion of my datastore was deleted, and the best explanation I
> can come up with is that the setLastModified calls started (silently)
> failing, leading to massive overkill in the sweep.
> There is also a call to setLastModified in FileDataStore.addRecord which is
> not strictly correct in the face of GC (i.e. it needs the resolution offset,
> and also must succeed if the file is writable or risk incorrect collection).
> Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
