[libdvdcss-devel] XDG specification - Cache folder

[Reimar Döffinger]

On Thu, Nov 03, 2011 at 01:04:10AM +0100, Ángel González wrote:
> Jean-Baptiste Kempf wrote:
> > Reimar was against it, because it could contain important data.
> >
> > See 
> > http://mailman.videolan.org/pipermail/libdvdcss-devel/2010-November/000574.html
> >
> > Best Regards,
> Thanks, I hadn't seen that reply.
> 
> 
> *Reimar Döffinger* wrote:
> > >/  This means placing dvdcss cache inside $XDG_CACHE_HOME folder with
> > />/  $XDG_CACHE_HOME as $HOME/.cache if unset.
> > /
> > XDG_CACHE_HOME is for "non-essential data". I have some doubts that
> > the DVDCSS cache belongs there.
> > Since the keys for some very short/simple (never investigated it, but some
> > titles from the Australian "Spaceballs" edition show this effect) titles
> > cannot be cracked, deleting might mean some DVDs will no longer be playable
> > if the drive region code was changed at some point.
> 
> Note that if $HOME/.dvdcss existed, my code still used it, so no data would be 
> lost by an upgrade.
> 
> However, the basis of Reimar that it "contains essential data" seems
> quite weak,
> given that it contains a CACHEDIR.TAG file, marking the folder as
> containing " cached
> information", suggested "to  avoid backing up, archiving, or otherwise
> unnecessarily copying such
> directories".

I wasn't aware of that. As said, I don't think it is quite appropriate,
even with CSS crypto keys are not necessarily easily possible to
recreate, I have never really considered it a cache and I have a disc
where I actually had to create a few of the cache files manually
to make the shorter titles play at all (they used numerically
incrementing keys so you only really _needed_ one, but dvdcss could
not figure out all on its own - if you wonder, it's the Australian
edition of Spaceballs).