Open Samhayne opened 1 year ago
I assume this is an NTFS drive? How did you created the hardlinks so I can try to reproduce?
Hi @0x90d !
Yes, it is an NTFS drive.
I retried...
Still: Windows 11 Version used: VideoDuplicateFinder 3.0.x 2023-06-18 (Daily snapshot)
Usually I use the LinkSkellExtension (https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html) Explorer-Add-On to create hardlinks.
But this time I did it from cmd:
Link:
C:\Temp\hardlinkTest2>mklink /h "4k Sample1.mp4" "4k Sample2 [HardlinkedWith1].mp4"
Verify:
Again:
And again:
Looks like a great tool after using a bit unfortunately for me almost impossible for me too use for MY intended purpose due to this HL issue. I'd love to help out here if I can. I know that the ignore HL options apply ONLY to adding files to the database and have tried using the CLEAR Db option in an attempt to see if this resolves the issue buy starting fresh. Even once just dumped the prefs and entire container to see if a REAL clean install would help.
Issue is also present on Linux (ZFS based LOCAL filesystem, that is also hosting the application in a docker container). HLs created DIRECTLY same linux host via ssh.
I can post full details and diagnostics but feel like this MAY be pointless and unfortunately it seems this project has been abandoned (no offense intended, most of us all have day jobs....)
I was pulling my hair out till I found the bug and hoped that chiming in here would save someone else time (and hair), while perhaps discovering someone who found a workaround? Ideally I would LOVE to see and option to take selected (dups) and CREATE HL (not symbolic links), to replace selected from other LARGER matches. I have a very HIGH level of HL on this media based server and unfortunately given how Tdarr works it of course breaks my HL as it transcodes across my disk so this option could potentially restore my previous HL configs and free up a good deal of space. Even with ZFS compress/dedup of said media it seems LIKELY there is some space saving here as I can't believe that 2 different encodes of the same video are likely to be EXACTLY the same (yeah I know it's deduced at a byte level but how can ANYTHING beat an inode link for compression right?).
If anyone has thoughts I would truly appreciate it. Either work arounds or even other tools assuming this doesn't pan out (I've been marking some content to ignore that is clearly HL (100% dup matches, then looking at Time/Date- also unfortunate that app doesn't have an option to use IS SAME date/time for a criteria in the selection critera- only absolute or relative date time values)
Again great tool I truly hope either the author or someone else picks up the torch here. I was an engineer for years and willing to help here anyway you think useful though no way I can fork and take on the entire codebase. Thanks again for any assistance.
--T
Environment
Windows 11 Version used: VideoDuplicateFinder 3.0.x 2023-06-18 (Daily snapshot)
Describe the bug
See snapshots
Snapshots