These files are not useful at this moment. You can ignore/delete them safely.
These files cannot be deleted since your program uses them and will generate them again next time I guess.
I’ll move them to the UserData folder in a future version. Currently you can just leave them there. They don’t contain any useful information and can be safely left in a conflict status when being synced.
Something I do with these types of situations is move the file to the local drive wherever you want it and then create a symbolic link back to the portable location. You can use mklink from an admin command line or you can use Link Shell Extension (free) which lets you create them via drag and drop (among dozens of other useful features).
Hi, just read through this and I’m a bit confused as we are at version 5 now and stuff doesnt lign up with the stuff mentioned here.
There are settings that should be shared through portable and there are settings that should not.
Right now the DiskSearch.db lies in the dropbox, as does the history (search history?) and the log. There is no reason for me to make this information portable, would’nt it be enough to have this in APPDATA of the current machine?
Other stuff is not directly tied to a local file system and can be reused everywhere, except:
- Keywords > Folder. Just hide / do not suggest entries that do not exist on the local system?
- Projects - I do not need to have those synced. This is highly specifc and should be fine to be setup per PC.
- History - This is also highly specific. No need to see the history of my workstation on my laptop.
Is there no way to have Preferences.json synced only except for hard-linking it dropbox on the OS level?
Hi,
The changes will be made in Listary 6. There won’t be conflicts of the disk index and history file then.
The installer version does that. The definition of portable is to not put anything outside of the exe folder.