Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-20212

Download as Zip temp content never gets cleaned up by Download Cleaner


    • Type: Service Pack Request
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 6.0
    • Fix Version/s: 6.1.1, 6.0.N
    • Component/s: Repository
    • Labels:
    • Bug Priority:
      Category 2
    • ACT Numbers:

      00982499, 00991222

    • Premier Customer:
    • Prioritization Score:


      Download as Zip for non admin users adds content type download:download to a new System Downloads folder with random guid that never gets cleaned up by Download Cleaner

      [Steps to reproduce]

      1. Log into Share as a non-admin user
      2. Do a "Download as Zip" action against a folder
      3. In Node Browser, navigate to workspace://SpacesStore -> /sys:system

      [Expected behavior]

      1. A new temporary content of type download:download gets added to System Downloads folder (sys:downloads) of workspace://SpacesStore/downloads_container
      2. The temporary content gets cleaned up by the Download Cleaner at a scheduled time later in the day (runs every hour)

      [Actual behavior]

      1. A new temporary content of type download:download gets added to a new System Downloads folder (sys:downloads) created on-the-fly with a random guild such as workspace://SpacesStore/9d98ead7-f99f-4aff-bfb3-0c296be50e52
      2. The temporary content never gets cleaned up by the Download Cleaner at a scheduled time

      [Suspected cause]
      Non-admin users don't have read permission to the original System Downloads folder (sys:downloads of workspace://SpacesStore/downloads_container) created by the system at first-time bootstrap, so when the user downloads a folder as zip and calls the method getOrCreateSystemChildContainer(..) of SystemNodeUtils.java, he doesn't have permission to see the original folder and hence the code tries to create a new folder as a fail-safe to ensure the System Downloads folder exists and the file can be written somewhere.

      When the Download Cleaner (runs as system user) comes around to clean the temporary file, it sees two System Downloads folders (the original one and the new one) but only cleans the first one it sees, which happens to be the original one and never cleans the one created by the non-admin user.

      The reason that Download Cleaner only cleans one of the two folders is because getSystemChildContainer method of SystemNodeUtils.java only returns the first node in the containerRefs list that it finds:

          public static NodeRef getSystemChildContainer(final QName childName, final NodeService nodeService, final Repository repositoryHelper)
              NodeRef system = getSystemContainer(nodeService, repositoryHelper);
              // Find the container, under system
              List<ChildAssociationRef> containerRefs = nodeService.getChildAssocs(
                      system, ContentModel.ASSOC_CHILDREN, childName);
              NodeRef container = null;
              if (containerRefs.size() > 0)
                  container = containerRefs.get(0).getChildRef();
                  if (containerRefs.size() > 1)
                      logger.warn("Duplicate Shared Credentials Containers found: " + containerRefs);
              return container;

      Throughout time, the repository will grow indefinitely and run out of disk space.

      The Node Browser shows the original System Downloads folder (workspace://SpacesStore/downloads_container) having the following permissions:

      Permission    Authority        Access
      FullControl   ROLE_OWNER       ALLOWED
      AddChildren   GROUP_EVERYONE   ALLOWED

      The System Downloads folder with the random UUID has the following permissions:

      Permission    Authority        Access
      Read          GROUP_EVERYONE   ALLOWED

      The original folder is created by ACS using this config: downloadsSpace.xml

      <?xml version="1.0" encoding="UTF-8"?>
      <view:view xmlns:view="http://www.alfresco.org/view/repository/1.0"
         xmlns:d="http://www.alfresco.org/model/dictionary/1.0" xmlns:cm="http://www.alfresco.org/model/content/1.0"
         xmlns:sys="http://www.alfresco.org/model/system/1.0" xmlns="">
         <sys:container view:childName="${system.downloads_container.childname}">
            <!-- By default, anyone can add children (new downloads) -->
            <!--  but not read, edit or delete other's sync sets -->
            <view:acl view:inherit="false">
                <view:ace view:access="ALLOWED">
                <view:ace view:access="ALLOWED">

      Please fix this on two fronts:

      1. For fresh installations, modifying permissions setting in downloadsSpace.xml
      2. For upgraded systems, modify the Download Cleaner to delete temporary files in both System Downloads folders (the one with GUID and the original one workspace://SpacesStore/downloads_container).

      For testing purpose, use the following setting to run the Download Cleaner every 30 seconds, change it to your needs:

      # Download Service Cleanup



          Issue Links




                • Assignee:
                  closedbugs Closed Bugs (Inactive)
                  ctan Craig Tan [X] (Inactive)
                • Votes:
                  0 Vote for this issue
                  6 Start watching this issue


                  • Created:

                    Structure Helper Panel