The Copy functionality seems to be skipping some files
Linux, Windows and Apple Mac File Hashing GUI Tool
Brought to you by:
tedtechnology
Menu
▾
▴
#6 The Copy functionality seems to be skipping some files
When using the Copy functionality (on the Linux64 version), QuickHash does not copy all the files in the source directory, even if I do not choose any file type. When I check the properties of the source folder, it shows a greater number of files than the ones copied by QuickHash. Is there a reason for this or it is a bug? Are these missing files the zero-byte files reported by QuickHash at the end of the copy process?
Given your previous ticket, I SUSPECT this is due to files that are located in a directory tree greater than 4K. Can you confirm if this is the case? If it is, then QH is currently unable to find files that are located in directories with a MAX_PATH greater than 260 chars in Windows or 4Kb in Linux. But the operating systems will, I suspect, know they are there.
Zero byte files are not HASHED but they are COPIED. Why? Because some software and systems need a file to exist even if it has no data in it. But to hash a zero byte file will result in a default initialisation hash of the appropriate algorithm being used to compute it. SHA1, for example, starts DA39...for a zero byte file, always. This is mis-leading. So to answer your question - no, it shouldn't be due to the zero byte files.
Are you able to help me further by detaling the source data structure, as explained above?
Thanks for the explanations, I will provide you more information asap. Also, would QH give an error message if, after copying, it finds more files in the source folder than in the target folder? If not, maybe it is also a problem if QH can find the missing file, but cannot copy it to the target directory because it would create a path > Length(MAX_PATH).
I will verify if:
(i) any folder in the source folder have path > Length(MAX_PATH), so QH is not finding them; and
(ii) if there is a missing file with path ≤ Length(MAX_PATH), if copying it to the target folder with the full path up to the source folder would create a folder with path > Length(MAX_PATH) and Linux is forbidding such a copy.
Also, it would be nice if QH could give an error or warning message if it finds a folder with path > Length(MAX_PATH), so we could keep track of what is not being copied or hashed. Is it possible to detect such situations?
I just discovered that the files that QH is not finding are files in hidden folders (folder with names beginning with a dot). Is it possible to make QH copy and hash also these files? Sorry, this problem had nothing to do with the lenght of the paths (but I am still interested in that feature request!). In case you are interested, I can send you the bash script I wrote to parse the html output of QH and verify the files.
Thanks,
Alessander
Confirmed behaviour. Thanks for letting me know. I was unaware. Will look into it.
I have worked out why ths is happening on Linux and fixed it but not yet released it.
On Windows, it will find hidden files already but not if they are in hidden directories. So I just need to adjust that before releasing.
For both versions, there is a "Hidden Files?" option to allow the user the choice to find and hash and\or copy hidden files. Will release soon.
v2.5.3 for Linux (64 bit) and Windows (32 and 64 bit) released. Hidden files should now be detected in Linux, even if they are in hidden directories. A 32-bit version for Linux will be released later tonight