[Building Sakai] Resources-within-Filesystem on Windows -- howto?

[Jim Eng]

Does the location "T:\resources" exist on the server, and does sakai  
have permission to read/write files in that folder?


On May 20, 2009, at 11:33 AM, will at serensoft.com wrote:

> Folks --
>
> Short version: how to get filesystem/bodyPath storage working under
> windows? On *nix this has always been a walk in the park :(
>
>
> Long version:
>
> It looks like this is the paradigm for specifying a drive/folder
> bodyPath at ...=T:\\resources
>
> But it's not creating any directory structure at all. No bodyVolumes,
> and no subfolders with the actual content, either.
>
> When trying to 'add' > 'text file' in the Saki interface, here's the
> error message logged:
>
> 11:23:58,187 http-80- 
> Processor23_org.sakaiproject.content.impl.DbContentService)
> WARN: : failed to write resource:
> /user/651cd081-b613-4697-9dfe-f7645621c537/sample text file :
> java.io.FileNotFoundException:
> T:\resources\s\2009\140\15\13bda7a5-e1c9-4ec3-9fc7-c25f5692b5c1 (The
> system cannot find the path specified) (2009-05-20 11:23:58,187
> http-80-Processor23_org.sakaiproject.content.impl.DbContentService)
> WARN: failed to write file from byte-array to file (2009-05-20
> 11:23:58,203 http-80- 
> Processor23_org.sakaiproject.content.impl.DbContentService)
> org.sakaiproject.exception.ServerOverloadException id=failed to write
> file from byte-array to file
> 	at org.sakaiproject.content.impl.DbContentService 
> $DbStorage.commitResource(DbContentService.java:1669)
> 	at  
> org 
> .sakaiproject 
> .content 
> .impl.BaseContentService.commitResourceEdit(BaseContentService.java: 
> 5467)
> 	at  
> org 
> .sakaiproject 
> .content 
> .impl.BaseContentService.commitResource(BaseContentService.java:5430)
> 	at  
> org 
> .sakaiproject 
> .content 
> .cover 
> .ContentHostingService.commitResource(ContentHostingService.java:519)
> 	at  
> org 
> .sakaiproject 
> .content 
> .tool.ResourcesAction.doCompleteCreateWizard(ResourcesAction.java: 
> 5655)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at  
> sun 
> .reflect 
> .NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at  
> sun 
> .reflect 
> .DelegatingMethodAccessorImpl 
> .invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at  
> org 
> .sakaiproject 
> .cheftool 
> .VelocityPortletPaneledAction 
> .actionDispatch(VelocityPortletPaneledAction.java:593)
> <snip>
>
> The path T:\resources\s\2009\140\15\13bda7a5-e1c9-4ec3-9fc7- 
> c25f5692b5c1
> looks legit -- do the backslashes need to be double-escaped within the
> Java code, perhaps?
>
> Earlier during startup, no warnings:
> INFO: init(): tables: CONTENT_COLLECTION CONTENT_RESOURCE
> CONTENT_RESOURCE_BODY_BINARY CONTENT_ENTITY_GROUPS locks-in-db: false
> bodyPath: T:\resources storage:
> org.sakaiproject.content.impl.DbContentService$DbStorage at 1d286180
> (2009-05-20 11:22:19,015
> Thread-1_org.sakaiproject.content.impl.DbContentService)
>
> What are we missing?
>
> This is for Sakai 2.5.x (v62432) on Windows 2003 Enterprise; The T:
> drive is ultimately intended to be a remotely-mounted network share,
> but for now (to keep variables to a minimum) it's just a local
> directory that's been "subst"ituted as a local drive, for testing.
> Tomcat is running as 'administrator' for now to make sure it's not a
> permission issue.
>
> -- 
> will trillich
> "Our only real economic security lies in our power to meet human
> needs." -- S.Covey, the 8th Habit
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"
>
>