-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Please cache downloads outside of the game directory #584
Comments
I think this is so important that I will start working on it immediately. Sorry for the delay, we were busy handling everything 0.90 related. |
I believe this would also affect netkan, and therefore MirrorKAN... Best check before something stomps all over your filesystem |
I would also like to see this feature. I sometimes run KSP from a RAM drive and I don't want to make the drive big enough to hold KSP+mods+the entire cache. Thanks! |
I'm fond of the XDG standard as well. It's not just for Linux. Although I've honestly no idea what people in Windows land expect for caching. Is there a standard there at all that we should be aware of? |
Judging by other programs it should go into either CommonApplicationData or LocalApplicationData depending if it should be per user. The paths to these can be found via Environment.GetFolderPath(Environment.SpecialFolder.{Name of special folder}). |
I would like manual control over where the files are put. Please do not hard code it, even to the OS' "expected" location. |
@taraniselsu : Do you have a preferred interface through which this may be achieved? If we defaulted to the XDG/OS standard location, but allowed a manual setting via Given that the CKAN cache should be the same for all installs (see @rafl's use-case in the top of this ticket), I'm going to suggest that the cache directory be stored in the Windows/Mono registry, rather than the CKAN one. |
@pjf I very much like that idea, the way I would do it (I don't know off the top of my head the best way to do
That should resolve to the correct path on all 3 major OSs, first preferring what was passed in to the command line, if nothing was defined it will then use the |
Just to throw in my non-existent knowledge of how mono really defines its paths: neither c:/ProgramData nor /usr/share on *x are writable for non-admin users. If we go this way, we really really really need to give users a way to define where they want their cache directory to be. |
@hakan42 I don't know how *x handles it but on windows |
I see rather strange assumptions here. /usr/share is NOT okay to store cache in. Neither as ProgramFiles. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Also a good note about cross-platform cache ir can be found there: http://www.chromium.org/user-experience/user-data-directory (except that hardcoded "C:") |
@legolegs no one here said program files is the correct place |
There is no other place to store cache in XDG standard. Unless skan is going to become a system-wide tool (like apt-get) there is no way to make something like /var/cache/ckan. |
I'm implementing @leftler 's version for now, though I will continue to follow the discussion here. |
@leftler 's version is just wrong in linux part. Firstly there is no such thing as XDG_CACHE_DIR, see this bug if you don't believe neither me nor XDG standard.
Secondly looking at this research there is a bug with Mono itself: on windows
|
@legolegs correction noted, thanks! |
This issue was moved to KSP-CKAN/CKAN-core#10 |
re-opening after the re-merge |
Would it be possible to get the cache directory to be user specified? Currently I have a 128GB SSD partitioned for SxS Linux/Windows/Home. I have multiple SATA drives, one which I have specified a directory for my Software Archive. I don't need the speed of the SSD for CKAN operations and the .../CKAN/downloads/ directory chews up a sizeable portion of the Home partition that could otherwise be put to better use. |
@7ranceaddic7 the workaround I use (windows box) is creating a symlink from the cache folder on my SSD to one on my HDD. Overall being able to choose a cache directory would be ideal, but all I can offer is a workaround. =) |
@SilverlightPony normally installation directories are read only by non privileged users (administrators/super users), it is not a safe assumption that a installation path will be writeable. The difference between %appdata% and %localappdata% is when you are in a domain files located in %appdata% will be copied to the domain controller on log off and copied to the computer when you log on, this lets files travel with you when you log off one machine then log on to another. files located in %localappdata% will always stay on the machine it was created on. |
I think the best thing initially, is to bypass the arguments about the ideal default location and implement a way for users to set the cache directory. Once that's in place, we can think about moving the default from where users currently expect to find it. |
I would suggest that when this is FINALLY implemented, that it default to the current behaviour. Give the users the ability to do the following:
I honestly don't understand why it's taking so long to do something so simple. You already have dialogs to select game location, so pretty much everything you need is already implemented. While I am not a contributer to this project (yes), I might consider it to get this feature |
Everyone loves a good bikeshed! |
Ok, so, are you saying that I responded too fast (I did read the entire thread, and actually opened an issue yesterday on this), or that I should actually do something about it? |
Lol, it's a joke. We're busy discussing minutiae rather than doing anything. @politas has tried to end it, by getting us to build the bikeshed now, and then we can settle on what colour to paint it later. |
Ok, but still, has there been any action? If not, then maybe tomorrow I'll take a look at setting up a local CKAN dev repo and seeing if I could do it myself |
So, this is what I'm planning on doing, seems to cover everything listed above:
Since I'm new to this code, please feel free to tell me what I missed :-) |
If anyone's started working on this privately, please say so! Your suggestion is in line with what @politas said, so if you want to work on it, @linuxgurugamer, go for it 😄. Then we can review some actual code in a PR. |
Need to make sure the directory choice is saved in the registry with the set of KSP installs, rather than the CKAN appearance settings that are saved per KSP install (to be honest, I'm not sure why we do that!), but yes, that's about the gist of it. This was on my personal list of coding projects, but behind a couple of other things. Feel free to have a stab at it. Have a quick read of the Developer guidelines in the CKAN wiki; there's some useful stuff in there. |
#1788, #1847 and #960 are all related (or can be related to this) This particular change (Allowing users to select a cache directory) is probably the first step. Second step is to get CKAN to recognise files in the cache directory by their hashes rather than their filenames, at which stage we will no longer care about what we call the files, and we can think about file naming under #1637. |
@politas as far as I know it already looks for just the hashes. I recall looking at it when working on the NetKAN code. |
It might test the cached files against the hash, but it doesn't find them that way. If you rename an item in the cache, it will re-download. |
Currently almost all of CKAN's data, including downloaded mods, is stored within the
CKAN
directory within a KSP installation. As a consequence, mods previously downloaded and cached in one KSP installation'sCKAN
directory will be re-downloaded when trying to install the same mods into another KSP installation.Especially with larger packages, such as the high resolution real solar system textures that weight in at something like 2GB, this gets annoying quickly, especially over slow downlinks.
Rather than caching downloads within KSP installations, please cache them in a more global location such as the user's home directory. On linux systems
$XDG_CACHE_DIR/ckan
would seem like a reasonable place.The text was updated successfully, but these errors were encountered: