Skip to content
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

Closed
rafl opened this issue Dec 14, 2014 · 39 comments · Fixed by #2535
Closed

Please cache downloads outside of the game directory #584

rafl opened this issue Dec 14, 2014 · 39 comments · Fixed by #2535
Assignees
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Enhancement New features or functionality ★★☆
Milestone

Comments

@rafl
Copy link
Member

rafl commented Dec 14, 2014

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's CKAN 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.

@rafl rafl added the Enhancement New features or functionality label Dec 14, 2014
@Ippo343 Ippo343 added the Core (ckan.dll) Issues affecting the core part of CKAN label Dec 15, 2014
@AlexanderDzhoganov
Copy link
Member

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.

@AlexanderDzhoganov AlexanderDzhoganov self-assigned this Dec 18, 2014
@AlexanderDzhoganov AlexanderDzhoganov added this to the v1.4.0 milestone Dec 18, 2014
@hakan42
Copy link
Member

hakan42 commented Dec 18, 2014

I believe this would also affect netkan, and therefore MirrorKAN... Best check before something stomps all over your filesystem

@taraniselsu
Copy link

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!

@pjf
Copy link
Member

pjf commented Dec 23, 2014

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?

@RichardLake
Copy link
Contributor

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}).

@taraniselsu
Copy link

I would like manual control over where the files are put. Please do not hard code it, even to the OS' "expected" location.

@pjf
Copy link
Member

pjf commented Dec 23, 2014

@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 ckan.exe ksp cache /path/to/cache would that be sufficient?

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.

@leftler
Copy link
Contributor

leftler commented Dec 26, 2014

@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 GetCacheDirFromCommandLine() or I would have made this a Pull Request)

private static string GetCacheDir()
{
    string cacheDir = GetCacheDirFromCommandLine();
    if(cacheDir != null)
        return cacheDir;        

    cacheDir = Environment.GetEnvironmentVariable("XDG_CACHE_DIR");
    if(cacheDir == null)
    {
        cacheDir = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);      
    }

    cacheDir = Path.Combine(cacheDir, "ckhn");      
    return cacheDir;
}

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 XDG_CACHE_DIR environment variable if it is assigned or the common application data folder (which resolves to C:\ProgramData on windows and /usr/share on Linux and OSX) and use the ckhn subfolder within it.

@hakan42
Copy link
Member

hakan42 commented Dec 26, 2014

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.

@leftler
Copy link
Contributor

leftler commented Dec 26, 2014

@hakan42 I don't know how *x handles it but on windows C:\ProgramData can have non elevated programs write to it no problems. Just open notepad as a non elevated user and save a text file in the C:\ProgramData folder and then navigate to the folder in explorer and you will see the file was saved. Perhaps you are thinking of C:\Program Files which is restricted to only allowing elevated users write to it (Well non elevated programs can still write to it too if they don't explicitly disable redirection by stating they are Windows Vista or newer compatible in their manifest, if they don't specify it in their manifest writes to C:\Program Files will get transparently redirected to %LocalAppData%\VirtualStore\Program Files to provide backwards compatibility for programs written for XP that assumed that the user would have admin rights.)

@legolegs
Copy link

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

$XDG_CACHE_HOME defines the base directory relative to which user specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

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:")

@leftler
Copy link
Contributor

leftler commented Dec 26, 2014

@legolegs no one here said program files is the correct place c:\Progam Files and c:\ProgramData are VERY diffrent folders with very diffrent purposes. Also XDG_CACHE_HOME is for user specific cache data, the options discussed so far are all non-user specific.

@legolegs
Copy link

Also XDG_CACHE_HOME is for user specific cache data, the options discussed so far are all non-user specific.

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.

@AlexanderDzhoganov
Copy link
Member

I'm implementing @leftler 's version for now, though I will continue to follow the discussion here.

@legolegs
Copy link

@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.

XDG_CACHE_HOME is the only one specified by the standard

Secondly looking at this research there is a bug with Mono itself: on windows CommonApplicationData expands to something like C:\Documents and Settings\All Users\Application Data which is okay, but Mono expands it to /usr/share which is absolute nonsense, it just like C:\windows\, it is not writable and is not supposed to hold any caches.
The proper way should be like this (I am not a C# programmer so I might be mistaken with syntax):

private static string GetCacheDir()
{
    string cacheDir = GetCacheDirFromCommandLine();
    if(cacheDir != null)
        return cacheDir;        

    cacheDir = Environment.GetEnvironmentVariable("XDG_CACHE_HOME");
    if(cacheDir == null)
    {
        cacheDir = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);      
        if (cacheDir == "/usr/share") //"/usr/share") is read only, this is bug in Mono
            cacheDir == Path.Combine(Environment.SpecialFolder.Personal, ".cache")
    }

    cacheDir = Path.Combine(cacheDir, "ckhn");      
    return cacheDir;
}

@AlexanderDzhoganov
Copy link
Member

@legolegs correction noted, thanks!

@Ippo343
Copy link
Contributor

Ippo343 commented Dec 27, 2014

This issue was moved to KSP-CKAN/CKAN-core#10

@pjf
Copy link
Member

pjf commented May 31, 2015

re-opening after the re-merge

@pjf pjf reopened this May 31, 2015
@pjf pjf added the ★★☆ label Jun 23, 2015
@pjf pjf removed this from the v1.6.0 milestone Jun 23, 2015
@7ranceaddic7
Copy link

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.

@mheguy
Copy link
Contributor

mheguy commented Jul 12, 2015

@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. =)

@leftler
Copy link
Contributor

leftler commented Jun 29, 2016

@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.

@politas
Copy link
Member

politas commented Jul 6, 2016

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.

@linuxgurugamer
Copy link
Contributor

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:

  1. At first time startup, select cache directory
  2. In settings give ability to select the directory.

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

@DinCahill
Copy link
Member

Everyone loves a good bikeshed!

@linuxgurugamer
Copy link
Contributor

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?
Not sure if you were being sarcastic or serious

@DinCahill
Copy link
Member

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.

@linuxgurugamer
Copy link
Contributor

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

@linuxgurugamer
Copy link
Contributor

So, this is what I'm planning on doing, seems to cover everything listed above:

  1. Add line to settings window showing path of cache directory
  2. Add 2 buttons to the right of the line to select cache directory, or use the default
  3. Add cache directory path to saved settings
  4. Update KSP.cs (DownloadCacheDir) to use the selected path

Since I'm new to this code, please feel free to tell me what I missed :-)
But hopefully this will get it working, and specifics can be updated later if needed

@DinCahill
Copy link
Member

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.

@politas
Copy link
Member

politas commented Aug 8, 2016

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.

@politas
Copy link
Member

politas commented Aug 19, 2016

#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.

@techman83
Copy link
Member

@politas as far as I know it already looks for just the hashes. I recall looking at it when working on the NetKAN code.

@politas
Copy link
Member

politas commented Aug 20, 2016

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.

@Olympic1 Olympic1 mentioned this issue Nov 14, 2017
14 tasks
@Olympic1 Olympic1 self-assigned this Nov 14, 2017
@Olympic1 Olympic1 added this to the 1.24.0 milestone Nov 14, 2017
@Olympic1 Olympic1 added ★★☆ Core (ckan.dll) Issues affecting the core part of CKAN and removed Core (ckan.dll) Issues affecting the core part of CKAN Pull request labels Nov 14, 2017
@Olympic1 Olympic1 modified the milestones: 1.24.0, 1.26 Mar 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core (ckan.dll) Issues affecting the core part of CKAN Enhancement New features or functionality ★★☆
Projects
None yet
Development

Successfully merging a pull request may close this issue.