Recognize symbolic links under Windows

[RevRagnarok]

I have symlinks in Windows, and they are not being recognized. Example: R:\Music\Amazon\ is a symlink to C:\Users\MyUser\Music\Amazon, so DupeGuru says that R:\Music\Amazon\MyAlbum\MySong.mp3 is a dupe of C:\Users\MyUser\Music\Amazon\MyAlbum\MySong.mp3. They're actually the same file with alternate paths to reach it.

[ghost]

Thanks for the suggestion, but unless a new maintainer is found, Windows support for dupeGuru is being phased out so there's not much chance for this feature ever to be implemented.

[michalfita]

Are symlinks recognized at all? With Python 3.2 and higher symbolic links on NTFS are supported in standard API.

[ghost]

@michalfita when creating a symlink, yes, it works on NTFS, but when comes the time to detect whether two paths are reference to the same content (same inode), I don't think that dupeGuru's current method of detection works on Windows.

[michalfita]

I don't have time to look into the code. Basic calls that allows detection of a symlink should work: os.path.islink() and os.lstat() are fixed in 3.2 for Windows links (the problem might be not all types).

[Dobatymo]

I would say this is a horrible bug which can cause loss of files. Not a feature request.

[brunetton]

Hi, I came across this issue while searching before opening an equivalent one for Linux. @arsenetar is this supposed to "work" on Linux ? I mean:

• ~/bar is a symlink to ~/foo
• so ~/bar/a is the same file than ~/foo/a
• but in duplicated files they are listed as duplicates files

(this is actually a simplification, as the actual trees are deeper)

[PJDude]

Hi, You may try this software: https://github.com/PJDude/dude Scanning here does not go through symbolic links, file is identified by device id (if necessary) and inode. Still under development but operational.

[brunetton]

Thank you for pointing this, I didn't found it while exploring existing recovery softwares ! I'll give it a try