Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.40alpha-svn589
-
None
Description
When scanning for files, CH stores the size of the file to be copied. This is used for calculating the total size of data to be processed.
However there are situations where the size retrieved during scanning is (or would be) invalid when copying:
1. The file is a symlink. The size retrieved when scanning is always 0. But when opening the file for copying, the size that can be retrieved using handle is the proper one. In this case it might be good to update the file size at a copying time, when the file is already open.
2. As Microsoft docs states, the size retrieved with FindFirstFile() and other might be out of date and the proper size needs to be read from the file handle - and that is not possible at scanning time because of the performance hit related to opening a file. It would be possible to handle at copying time.
3. File changes its size during operation. In this case even reading file size at file open time, won't guarantee the file size won't change. This requires updating the file size of the associated object on the fly.
The best course of action seems to be to update the file size of the associated file info object when opening the source file (retrieving the size through file handle) and then updating the file size when copying (as it might be bigger or smaller than it used to be when scanning).
Attachments
Issue Links
- relates to
-
CH-125 Handle processing errors as feedback actions instead of putting task in an error state
- Open