Store files in the proper location on Windows.
See original GitHub issue- OS: Windows
- Version of IPFS Desktop: 0.12.2
Describe the bug Installing IPFS Desktop on Windows results in folders in %USERPROFILE% as well as cache and DB files in the roaming profile.
To Reproduce Steps to reproduce the behavior:
- Install IPFS Desktop on Windows
- Notice that you have a
.ipfs
and.ipfs-desktop
folder in%USERPROFILE%
and%APPDATA/IPFS Desktop
contains cache files, databases, blob storage, etc.
Expected behavior
Cache files, file storage, databases, and per-machine configuration should all be stored in %LOCALAPPDATA%/ipfs/
. Per user configuration (I’m not sure if IPFS has any of this, maybe the list of pinned files?) should be stored in %APPDATA%/ipfs/
. Nothing should be stored in %USERPROFILE%
(aka: %HOME%
) unless the user *explicitly tells the app to do so such as via a save dialog box.
Additional context Both Linux and OSX also have environment variables that instruct applications where the appropriate place for files is. I believe it is called XDG_CONFIG though I’m not personally familiar with it.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:11 (5 by maintainers)
Top GitHub Comments
I submitted an issue to get
go-homedir
library fixed: https://github.com/mitchellh/go-homedir/issues/30I believe there are other similar libraries that better support different data types so if the author of
go-homedir
is resistant to this change, perhaps switchinggo-ipfs
to a different library would be the right course of action long term. Either way, migration will need to be handled still so the library getting fixed isn’t the final solution.My concern with this strategy is that this issue has been open with Electron for almost 4 years now, and until they fix it the default of Electron is to be a bad citizen. This means that IPFS Desktop will continue to be a bad citizen indefinitely, since there is no light at the end of the tunnel for Electron fixing the issue.
That being said, I understand your position and appreciate you clearly laying out why you are weakly opposed to it. I certainly don’t envy the maintainers of IPFS Desktop being put in this situation.
All in all, I agree with all 3 of your suggested paths forward. They are prudent and get things to a better place eventually without risking too much code complexity or breakage along the way.
A
.
prefix on Windows does not alter visibility and it causes some mild annoyances in Windows Explorer since you cannot set a folder to that name in some contexts. However, applications are free to do whatever they want within their subfolders of%LOCALAPPDATA%
so if for some reason having a folder without a leading.
is difficult then letting it stay I think is fine and still respects Windows folder hierarchy.$user/AppData/Roaming
should be%APPDATA%
. It is configurable, and won’t always be a subdirectory of%USERPROFILE%
nor will it necessarily be a sibling of%LOCALAPPDATA%
(in fact, it is common to have them on different drives). Does IPFS currently use%APPDATA%
,%LOCALAPPDATA%
, and%USERPROFILE%
or is it manually constructing those paths? If it is manually constructing those paths then that should be fixed as well.Something to be aware of is that Electron’s default locations are bad and you should not assume that Electron will put data in the right place by default. Electron by default considers hundreds of megabytes of cache data to be “app config” and it stores it in a location that is network synced/backed up. Given this, I recommend moving the Electron stuff to
%LOCALAPPDATA%
since it can grow pretty large and is transient data (not actual user-configuration data).In general, my advice is to use
%LOCALAPPDATA%
for everything as a default unless your application is specifically designed to support roaming/network synced configuration. I don’t know if IPFS is currently designed for synced user configuration, though it would be pretty cool if it was. In particular, I would like it if my list of pinned files was synced and when I switched computers IPFS would automatically fetch pinned items and remove pins from items I unpinned on another computer. However, I would not want the actual pinned content to live in a roaming location, just the hashes.