Loading Result of 'Scan Type: Folders' shows only '---' in every table cell

[YEAS175m3]

Describe the bug
I came across this problem when scanning my NAS the whole day for duplicate folders. Seeing how many duplicates I had in the result table I decided to save the result to make my delete-decisions the next day.
When Loading the result it took a while (3,66 MB result file, I assume checking the existence of the paths again) but when it finally showed the dupeGuru Results-window, every single cell in every column/line showed ---.
The amount of existing table lines could be correct and in the status bar it showed the amount of duplicate folders and the total size.
When using Open Selected with Default Application on a highlighted entry it opened Windows Explorer with the correct Folders.
So the information is definitely loaded and internally available, but it does not show the file names (folder names in this case), folders, kind, size and so on in the table. Same when calling the Details for an entry, also only ---.

Unfortunately this makes it impossible to delete duplicates, so I am running the scan again now and delete the duplicates immediately without closing dupeGuru. But for other Users or my own future uses a fix of this bug would be helpful!

• I reduced the amount of entries in the result file drastically, it was loaded faster, but same behavior.
• I created a test folder with one text file, copied the folder and run the scan again, same behavior.
• I tested it with Scan Type: Contents and loading the result worked fine and showed the file name and folders.
• I uninstalled and re-installed dupeGuru, same results.

To Reproduce
Steps to reproduce the behavior:

1. Create some dupeguru_test folder
2. Create a Folder_1 folder in this dupeguru_test folder
3. Create a text file with some example text inside the Folder_1 folder
4. Copy & Paste the Folder_1 folder inside the dupeguru_test folder and name it Folder_1_Copy
5. Add dupeguru_test folder to dupeGuru
6. Configure dupeGuru like this:
   
7. The result should look like this:
   
8. Save Results... in the dupeguru_test folder for example
9. Close dupeGuru
10. Start dupeGuru
11. Load Results from saved file
12. After importing the file the dupeGuru Results- and Details-windows looks like this:
    
13. The debug.log shows this errors:

    2020-06-24 10:49:44,323 - WARNING - Exception on GetDisplayInfo for T:\dupeguru_test\Folder_1:
    2020-06-24 10:49:44,327 - WARNING - Exception on GetDisplayInfo for T:\dupeguru_test\Folder_1_Copy:

Expected behavior
When loading the results of a Scan Type: Folders-search the table should show the values (file name, folders, ...) in the result table like the result windows does right after the scan.

Desktop:

• OS: Windows 10 Pro (German) - Version 2004 - Build19041.329 - no Updates pending
• dupeGuru Version 4.0.4 RC (x64) (re-downloaded/re-installed from github on 06-24-2020

Additional context
debug.log

Note of Thanks
I love open source software like this and I want to thank everyone who contributes to such projects!
I hope with my first reported problem I can also contribute something - I hope the bug report was okay so far 😉

[glubsy]

Thanks for the (very good) bug report. I can confirm this happens also on (Arch) Linux.

For reference, the exception is generated here. The type of exception thrown is a NotImplementedError, so it must be hitting this virtual function.

The problem comes after reading the xml data, in _get_export_data(). The dupe passed to the function is of type "core.fs.Folder", but it seems that we need to call the function defined in core.se.fs.Folder instead (which seems to be the expected implementation) so perhaps the type of this dupe is wrong (core.fs.Folder)?
The DupeGuru.results.groups is most likely not populated with the appropriate type in this specific case.
In which case the problem would be located somewhere in core.results.py, possibly where we initialize the groups data member.

Anyway, not sure why that implementation is not being called here.

[glubsy]

I have written a temporary fix here which works so far, but it's only redirecting the exception handling to the appropriate function which is in core.se.fs.Folder.
Not yet sure how to call this automatically, need to investigate more.
If anyone has a better insight, let us know.

[glubsy]

Turns out maybe this simple fix is actually the solution? I'll make a pull request for the time being, but it probably needs some more testing (also might need to update the test suite, I'm not sure).

[arsenetar]

@YEAS175m3 Thanks, for the detailed report.
@glubsy Thanks, for fixing this issue.
Since this has been resolved, I am marking this issue as closed.