Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39193

Outstanding issues with SAK-800



    • Type: Bug
    • Status: CLOSED
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.6.x
    • Fix Version/s: 2.9.x
    • Component/s: Kernel
    • Labels:
    • Property addition/change required:
    • CLE Team Issue:
    • Previous Issue Keys:


      This jira is just to note the outstanding issues that we had with SAK-800 since it's now in the kernel. The current SAK's comments are pretty confusing. Currently this code is commented out AND disabled via property. I had some discussion with Alessandro Oliveira but no communication since then. Most of the issues involved lack of user feedback and performance issues with large zip files.

      Most of them really weren't major and the tool was close to being ready to release. All of the code is still there in kernel just the link in the dropdown is commented. Pretty much the biggest ones were:

      • It does not do any permission checking and always displays the zip/unzip option. It really should verify that the person has permission to write to the location before presenting the zip/unzip option. Optionally it would be okay if a the permission exception that happens actually returned a message.
      • When things go wrong with the feature, there is no feedback to the user that things went wrong.
        Lots of things silently go wrong that we tested on
      • If you're uncompressing a file that really isn't a zip
      • Some folders in Admin Resources fail to compress (NPE)
      • There's an exception that should display a message when compressing an empty folder
      • Your other issue mentioned with extracting files that already exist. It seems like perhaps the best solution for this would be to always extract the files to a directory with the same name as the archive. If that directory exists, create a new directory. I think this is how most of the zip programs work.

      For instance if you have testzip.zip - It will check for the existence of the folder testzip. (I think it does this now) If it doesn't exist it will extract it into the into the folder testzip. If it does exist it will check for testzip.1, and continue until it finds a folder it can uncompress into. (testzip.2, testzip.3)

      I think that was all I knew of.

        Gliffy Diagrams



            1. content_KNL-273.patch.txt
              3 kB
            2. kernel_KNL-273.patch.txt
              16 kB
            3. kernel_KNL-273-extra.patch.txt
              3 kB
            4. KNL-273_content-5.diff
              4 kB
            5. KNL-273_kernel-4.patch
              11 kB
            6. KNL-273_sak27x_v2.patch
              20 kB

              Issue Links



                  aaronz Aaron Zeckoski (Inactive)
                  jonespm Matthew Jones
                  0 Vote for this issue
                  10 Start watching this issue



                      Git Integration