[ 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.