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

[Anthony Whyte]

Property protected per your request (see KNL-155 for more details).   
Hopefully, some kind soul will sort out SAK-800 to the satisfaction  
of all.

Anth


On Apr 16, 2009, at 1:59 PM, Adam Marshall wrote:

> We use SAK-800 in production and whereas the zipping up is a bit  
> flaky, the
> unzipping seems to work fine.
>
> As we have to apply the SAK-800 patch for each build, we'd like to  
> see it in
> the code base protected by a property that by default disables the
> functionality.
>
> Perhaps if it is available in the download, some kind soul may fix the
> outstanding problems (and add an option to save the ZIP file on  
> one's local
> machine!)
>
> Adam
>
> | -----Original Message-----
> | From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-
> | bounces at collab.sakaiproject.org] On Behalf Of Anthony Whyte
> | Sent: 16 April 2009 18:16
> | To: Sakai-Dev Developers
> | Cc: Sakai QA
> | Subject: [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources  
> archive
> | filehandling issues
> |
> | 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/20090417/77de4c66/attachment.bin