Save scan results to file(s)

[Lister0fSmeg]

I do not see any option to save the scan results to a file so that it can be re-loaded at a later time so that the duplicates can be processed at a later time. Scanning large hard drives can take a great deal of time and I do not want to have to keep repeating that unnecessarily. Finding enough time to process the results, selecting and verifying files to delete is not something that I want to rush because I do not want to lose files by making any mistakes. It can take a considerable amount of time when there are a massive amount of duplicates and windows frequently likes to reboot to install updates.

Therefore any chance that a save feature can be implemented?

[qarmin]

This is in my TODO list and maybe even will be available in 4.0 version.

[m-stefanski]

I am having problem finding save option in GUI 7.0.0, when running in docker. Is there something I am missing?

[ZF-Student]

Once "Duplicate Files" results are displayed, and saved, where does Hiccup save the file? I can see the JSON cache file in the cache folder but don't see a 'saved' file. In /home/<user_name>/.var/app/com.github.qarmin.czkawka/data, there is no 'data' file.

[huntekah]

For me, using docker's czkawka image jlesage/czkawka, I just mount config's directory as a volume:

    volumes:
      - "/local_pc/docker/czkawka/config:/config:rw"

and saved results appear in config directory as:

config/results_duplicates_compact.json
config/results_duplicates_pretty.json
config/results_duplicates.txt
config/results_similar_images_compact.json
config/results_similar_images_pretty.json
config/results_similar_images.txt

[almostwitty]

It's great that the save feature has been implemented - but I don't see how to load those saved results back in... ?

[qarmin]

It is not possible (yet?)

Loading results from a file is significantly more complex than saving them, because it requires an additional validation layer and duplication of the logic that currently writes results into the model

Implementing this would add approximately 1.5K-2K lines of code and would require a refactor to unify and simplify how results are saved into the model. Without that, the same data would need to be kept in sync in two separate and fairly complex code paths, which would be a long-term maintenance burden

[almostwitty]

ok, thanks for letting me know. Hopefully you'll find the time or energy to enable loading back in the results at some future stage, which will mean I can use this program - otherwise I can't quite see the rationale behind implementing the save feature in the first place.

Thanks for all your hard work!

[qarmin]

There were two reasons:

• txt format, it allows users to manually process files and review the results even after closing the application.
• json format, it allows users to easily load the data into their own scripts for further processing

Neither txt nor json format were designed with loading data into the application in mind, so it is unclear whether introducing a completely new format would be necessary, for example a csv-like format or plain csv