Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-21825

Temporary files not always deleted when copying from DFS to FS

    Details

      Description

      In eZDFSFileHandlerMySQLiBackend::_fetch, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

      When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

      When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

      The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

      The temporary file should be deleted inside the loop by the dfshandler if the copy was not successful.

      Note:
      A follow up story – EZP-23254 – will deal with the case when filesize returned are invalid because of FS issues.

        Issue Links

          Activity

          Jérôme Gamez created issue -
          Yannick Roger (Inactive) made changes -
          Field Original Value New Value
          Affects Version/s 5.3 [ 11282 ]
          Yannick Roger (Inactive) made changes -
          Link This issue relates to EZP-23092 [ EZP-23092 ]
          Eduardo Fernandes (Inactive) made changes -
          Status Open [ 1 ] Confirmed [ 10037 ]
          Yannick Roger (Inactive) made changes -
          Status Confirmed [ 10037 ] InputQ [ 10001 ]
          Yannick Roger (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Yannick Roger [ yannick.roger@ez.no ]
          Yannick Roger (Inactive) made changes -
          Status Development [ 3 ] Documentation done [ 10011 ]
          Affects Version/s 2014.07 [ 13481 ]
          Affects Version/s 5.4-dev [ 13485 ]
          Fix Version/s 5.4 [ 13180 ]
          Fix Version/s 2014.09 [ 13681 ]
          Paulo Nunes (Inactive) made changes -
          Status Documentation done [ 10011 ] QA [ 10008 ]
          Assignee Yannick Roger [ yannick.roger@ez.no ] Paulo Nunes [ paulo.nunes@ez.no ]
          Paulo Nunes (Inactive) made changes -
          Assignee Paulo Nunes [ paulo.nunes@ez.no ] Eduardo Fernandes [ eduardo.fernandes@ez.no ]
          Eduardo Fernandes (Inactive) made changes -
          Flagged Impediment [ 10000 ]
          Yannick Roger (Inactive) made changes -
          Description In {{eZDFSFileHandlerMySQLiBackend::_fetch}}, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

          When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

          When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

          The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

          The temporary file should be deleted *inside* the loop.
          In {{eZDFSFileHandlerMySQLiBackend::_fetch}}, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

          When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

          When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

          The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

          The temporary file should be deleted *inside* the loop by the dfshandle if the copy was not successful.

          *Note:*
          A follow up story will deal with the case when filesize returned are invalid because of FS issues.
          Yannick Roger (Inactive) made changes -
          Description In {{eZDFSFileHandlerMySQLiBackend::_fetch}}, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

          When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

          When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

          The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

          The temporary file should be deleted *inside* the loop by the dfshandle if the copy was not successful.

          *Note:*
          A follow up story will deal with the case when filesize returned are invalid because of FS issues.
          In {{eZDFSFileHandlerMySQLiBackend::_fetch}}, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

          When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

          When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

          The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

          The temporary file should be deleted *inside* the loop by the dfshandler if the copy was not successful.

          *Note:*
          A follow up story will deal with the case when filesize returned are invalid because of FS issues.
          Eduardo Fernandes (Inactive) made changes -
          Link This issue relates to EZP-23254 [ EZP-23254 ]
          Eduardo Fernandes (Inactive) made changes -
          Description In {{eZDFSFileHandlerMySQLiBackend::_fetch}}, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

          When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

          When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

          The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

          The temporary file should be deleted *inside* the loop by the dfshandler if the copy was not successful.

          *Note:*
          A follow up story will deal with the case when filesize returned are invalid because of FS issues.
          In {{eZDFSFileHandlerMySQLiBackend::_fetch}}, a file gets copied from the DFS to the local FS to a unique filename and then renamed to the target filename.

          When the filesize of the copied file doesn't match the filesize of the DFS file, the copy is performed again until the filesizes match or the maximum number of tries is reached.

          When the maximum number of tries is reached, the copy is considered unsuccessful and the temporary file gets deleted.

          The Problem is: The name of the temporary file changes with each loop, but gets deleted only after the loop. When the maximum number of tries is set to 3, this means that 2 temp files remain on the file system.

          The temporary file should be deleted *inside* the loop by the dfshandler if the copy was not successful.

          *Note:*
          A follow up story -- EZP-23254 -- will deal with the case when filesize returned are invalid because of FS issues.
          Paulo Nunes (Inactive) made changes -
          Flagged Impediment [ 10000 ]
          Yannick Roger (Inactive) made changes -
          Fix Version/s 5.3.3 [ 13484 ]
          Yannick Roger (Inactive) made changes -
          Affects Version/s 5.3.2 [ 13483 ]
          Eduardo Fernandes (Inactive) made changes -
          Assignee Eduardo Fernandes [ eduardo.fernandes@ez.no ]
          Status QA [ 10008 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Yannick Roger (Inactive) made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Assignee Yannick Roger [ yannick.roger@ez.no ]
          Yannick Roger (Inactive) made changes -
          Affects Version/s 5.2 [ 12582 ]
          Yannick Roger (Inactive) made changes -
          Fix Version/s 5.2 Maintenance [ 12782 ]
          Yannick Roger (Inactive) made changes -
          Status Reopened [ 4 ] InputQ [ 10001 ]
          Yannick Roger (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Yannick Roger (Inactive) made changes -
          Status Development [ 3 ] Documentation done [ 10011 ]
          Paulo Nunes (Inactive) made changes -
          Status Documentation done [ 10011 ] QA [ 10008 ]
          Assignee Yannick Roger [ yannick.roger@ez.no ] Paulo Nunes [ paulo.nunes@ez.no ]
          Paulo Nunes (Inactive) made changes -
          Rank Ranked lower
          Paulo Nunes (Inactive) made changes -
          Assignee Paulo Nunes [ paulo.nunes@ez.no ] Eduardo Fernandes [ eduardo.fernandes@ez.no ]
          Eduardo Fernandes (Inactive) made changes -
          Assignee Eduardo Fernandes [ eduardo.fernandes@ez.no ]
          Status QA [ 10008 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Eduardo Fernandes (Inactive) made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Yannick Roger (Inactive) made changes -
          Status Reopened [ 4 ] InputQ [ 10001 ]
          Yannick Roger (Inactive) made changes -
          Status InputQ [ 10001 ] Development [ 3 ]
          Assignee Yannick Roger [ yannick.roger@ez.no ]
          Yannick Roger (Inactive) made changes -
          Status Development [ 3 ] Documentation Review done [ 10011 ]
          Affects Version/s 5.1 [ 11280 ]
          Fix Version/s 5.1 Maintenance [ 12301 ]
          Eduardo Fernandes (Inactive) made changes -
          Fix Version/s Customer request [ 11018 ]
          Miguel das Neves Jacinto (Inactive) made changes -
          Status Documentation Review done [ 10011 ] QA [ 10008 ]
          Assignee Yannick Roger [ yannick.roger@ez.no ] Miguel das Neves Jacinto [ miguel.jacinto@ez.no ]
          Miguel das Neves Jacinto (Inactive) made changes -
          Assignee Miguel das Neves Jacinto [ miguel.jacinto@ez.no ]
          Status QA [ 10008 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          André Rømcke made changes -
          Workflow eZ Engineering Scrumban Workflow [ 59736 ] EZ* Development Workflow [ 84426 ]
          Alex Schuster made changes -
          Workflow EZ* Development Workflow [ 84426 ] EZEE Development Workflow [ 123079 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Jérôme Gamez
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: