[ https://issues.apache.org/jira/browse/JCR-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888769#action_12888769 ]
Thomas Mueller commented on JCR-2674: ------------------------------------- Thanks a lot for the patch! It is now committed (in the trunk only so far). I made an additional change in addRecord: currently it's "if (file.lastModified() < now)" - I will change that to "if (file.lastModified() < now + ACCESS_TIME_RESOLUTION)". Again about addRecord: your code only throws an exception if file.canWrite() returns true - is that for read-only file systems / access rights? Or does it have a different reason? > check for -1 return value from Property.getLength You mean the exception from FileDataStore.getRecordIfStored() is swallowed? That's wouldn't be nice. Anyway, your change is OK. > 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 > 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.