bodyPathDeleted silently defaults to {sakai.home}/null
Description
Attachments
- 05 Aug 2014, 04:30 PM
is related to
relates to
Activity
Hudson CI Server September 2, 2014 at 9:18 PM
UNSTABLE: Integrated in sakai-10-java-1.7 #115 (See http://builds.sakaiproject.org:8080/job/sakai-10-java-1.7/115/)
Merging https://sakaiproject.atlassian.net/browse/KNL-1290#icft=KNL-1290 - System won't start with https://sakaiproject.atlassian.net/browse/KNL-1286#icft=KNL-1286 (matthew@longsight.com: rev 312648)
Matthew Jones August 26, 2014 at 12:41 PM
I think that having bodyPathDeleted defined or not be the flag for whether or not this feature is enabled was probably a bad decision in the original patch, but I didn't write that or spend time to fix that. I'm not sure what the issue is with OSP but that would only be related to 10.x as it's removed from trunk, making it a little harder to test. Resources probably also shouldn't show the trash button in the UI if the trash feature is turned off. (But I feel like this is always on)
So probably there is more related followup.
Matthew Jones August 26, 2014 at 12:37 PM
Please don't reopen tickets with existing merges to released versions as it makes it difficult to figure out the branch management, if this is a related issue on a resolved ticket create and link it.
Charles Hedrick August 26, 2014 at 12:33 PM
I should note that with the initial patch but not my fix, sakai will fail to start if OSP. Hence the original https://sakaiproject.atlassian.net/browse/KNL-1286#icft=KNL-1286 is arguably a Blocker-level regression, though only if your site doesn't have bodypathdeleted defined.
Charles Hedrick August 26, 2014 at 12:30 PM
You also need
— kernel-impl/src/main/java/org/sakaiproject/content/impl/BaseContentService.java (revision 5677)
+++ kernel-impl/src/main/java/org/sakaiproject/content/impl/BaseContentService.java (working copy)
@@ -4698,6 +4698,9 @@
*/
public void addResourceToDeleteTable(ContentResourceEdit edit, String uuid, String userId) throws PermissionException, ServerOverloadException
{
+ if (m_bodyPathDeleted == null)
+ return;
+
String id = edit.getId();
String content_type = edit.getContentType();
With that things seem to work without a delete path.
(The reason we don't need this is that we snapshot our file system. We can find deleted files if we need to anyway, and don't need a second copy.)
If you don't explicitly define
bodyPathDeleted@org.sakaiproject.content.api.ContentHostingService
it appears to default to {sakai.home}/null. This is unhelpful in a cluster, as you get app-server specific locations like /usr/local/sakai/null/vol1/... and in practice it makes deleted files unrecoverable as the file contents are located on a specific app server and may be removed by updates, etc.
The code should default this to something more sensible, e.g. {bodyPath}/deleted and also log the path used in catalina.out on startup.
Currently bodyPath is logged but not bodyPathDeleted
2014-08-05 13:35:26,535 INFO localhost-startStop-1 org.sakaiproject.content.impl.DbContentService - init(): tables: CONTENT_COLLECTION CONTENT_RESOURCE CONTENT_RESOURCE_BODY_BINARY CONTENT_ENTITY_GROUPS locks-in-db: false bodyPath: /data/sakai/content storage: org.sakaiproject.content.impl.DbContentService$DbStorage@791fe54c