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