[WG: Sakai QA] KNL-155/SAK-16036/SAK-800: Resources archive file handling issues

[Anthony Whyte]

In April 2008 code was merged into trunk /content (r 45419, 45421)  
and the API and  service modifications were later repackaged in the  
kernel (K1) in order to provide the ability to create/extract from  
archive file types (e.g., .zip, .tar, .tgz).  The most recent  
comments in SAK-800 combined with recent testing by Matt Jones of  
UMich (as reported in KNL-155) indicates that this feature still has  
a number of problems associated with it (Matt's comments are below).

Given these concerns and the short time frame that now exists with  
respect to the upcoming 2.6.0 release Matt has suggested the  
following options in lieu of fixing it:

1) remove it
2) comment it out
3) wrap it in a property setting (enable/disable) and add the new  
property (e.g., resources.zip.experimental = false) to /config  
default.sakai.properties.  Default = disabled.

I'd appreciate your opinion on the matter.

Cheers,

Anth


Further reading:

http://bugs.sakaiproject.org/jira/browse/KNL-155
http://bugs.sakaiproject.org/jira/browse/SAK-16036
http://bugs.sakaiproject.org/jira/browse/SAK-15995
http://bugs.sakaiproject.org/jira/browse/SAK-800

KNL-155/SAK-16036.  Matt Jones comments:

"Since there were still so many issues with SAK-800, it's status was  
recently brought up by Stephen on the QA mailing listlist, Because of  
followup concerns and based on the comments for on the jira for  
SAK-800, I believe that it shouldn't be released in the final build.  
This contributed patch was merged into trunk in an unfinished state  
and made it into the 2.6 release. Ideally the issues in this patch  
should be resolved but this will unlikely happen before the release  
and it should not hold it up.

Here were my comments on the QA list:

- There is no feedback to the user when anything goes bad, as the  
link appears on resources that you don't have permission to (this  
could be checked for permission first in FolderCompressAction) and  
there was an NPE as indicated on the jira.
- No solution for extracting files that already exist in resources
- If the zip file or number of contained files is large, the  
extraction/compression might take a long time and the UI will block  
interaction rather than threading it. An alternative would be to have  
it check sizes in advance. I think I even tested a zip file  
containing 0K small files and it took almost 5 minutes to uncompress.
- I wasn't sure if compressing large files/directories ran into  
memory errors or not, some of these edge cases should be tested.
- I don't think I tested what happens operated on really isn't a zip  
file, just has a .zip extension There's no error messages shown by  
the tool, so
- More errors in general need to be show to the user.

This should be able to be easily disabled in the UI, you'd just have  
to wrap up
the actions in FileUploadType/FolderType
  actions.put(ResourceToolAction.EXPAND_ZIP_ARCHIVE, new  
FileUploadExpandAction());

I don't know if we'd want to wrap these up with a user settable  
sakai.properties value, comment it out of the code or unmerge this  
patch. It would be nice to eventually see it working. I would  
probably vote to disable via property just to give someone interest  
on possibly working on it again. Like resources.zip.experimental =  
false."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090416/a5fc03c6/attachment.bin