Create Hardlinks fails on read-only files (Ticket #911209)

[CP44]

Duplicate Cleaner Pro 3.2.7
Windows 7 x64 SP1
Target drive: NTFS v3.1 (from fsutil fsinfo ntfsinfo)
"Create Hardlinks" feature fails when targeting read-only files for "removal".

There are 2 different outcomes:
1. An access denied error reporting dctmp_* will leave the "Delete, Rename or Hardlink Files" window believing it has an operation in progress. The only known fix is to restart the program; scanning files and refreshing the view do not fix it.
2. A properly handled access error opens the Log window to declare access to the path was denied. The "Delete, Rename or Hardlink Files" window behaves normally after this error.

Verification:
I have a large NTFS drive that now contains backups from a PC and a flash drive. After unsuccessfully trying to hardlink all duplicate files with "newer" modified times so that they would be linked to older files (resulting in problem behavior 1), I restarted Duplicate Cleaner and targeted a single copy of "ntdetect.com old" which had various matches to "ntdetect.com" and "ntdetect.com old". I opened its path in Explorer, marked it read-only, and attempted to hardlink the file. This resulted in error behavior 2, with this log text:
==
Delete/move Error: E:\[Path trimmed]\ntdetect.com old : Access to the path 'E:\[Path trimmed]\ntdetect.com old' is denied.

1 Files(s) could not be hard linked.
0 File(s) have been Hard Linked.
==
During additional testing (see below for A & B description), I have verified that behavior 1 occurs when file A and B are read-only. Behavior 2 occurs when only file A is read only. During testing on Windows 7 x64, it was also noticed that deleting the dctmp_* hardlink copy cleared the read-only attribute on the link target, potentially affecting future tests.

Would this be a valid procedure to implement? File A is selected to be removed, file B is the target of a hardlink (dctmp_* appears to be the hardlink copy), file A is removed regardless of its attributes (read-only), dctmp_* is moved into the place of File A. If this seems unsafe, there could be an override preference; or users can continue with current option of ensuring that files targeted for removal are not set to read-only.

As users have posted on the forum years ago, being able to hardlink duplicates within backups is a primary use for this program; being able to keep attributes (read only, archive, hidden, system) is desirable to have consistent states, not have to clear read-only on every file in a target directory (or drive) to allow Duplicate Cleaner to function, especially if some users will be setting read-only to every file in their backups. It appears as though the attribute are shared across links in my test case.

[DigitalVolcano]

Thanks for the report. I'll log as a bug.

Version 4 (currently in beta) uses a new engine for hardlinking. This will perform the hard link even if the file is read-only (either file)