Check if 'rtorrent.dat' cache file exists/readable before using it

[Micdu70]

Close #1911

[Novik]

Reason of this?

[Micdu70]

The only reason is if the "share" folder has wrong permissions ; ruTorrent can still be loaded ( and we can even add a warning message about permissions issue, maybe? ).

[Micdu70]

But... yeah... there is no "real" reason for this, there is already an error message if "settings" folder is not readable by webserver user. So I will close this...

[Novik]

If share folder has wrong permission, then we must generate an error.
We can't retrieve all properties from rtorrent on the each call to ruTorrent (they is used in a lot of places), this is not good for performance.

[Novik]

#1911 has relation to the wrong permission of share folder, right? If yes - then why user can't see an error message? He is a blind, or we have an error in diagnostic?

[Micdu70]

@Novik: This user removed the rtorrent.dat file and I still don't really understand why he did that... He tried to find a "bug" when it's normally impossible to reproduce...

[Novik]

But if he delete this file, then ruTorrent must to create it again when user reload interface (on getplugins.php call). Why this wasn't happening?
Or he delete this file every time? >:()

[Micdu70]

With some "weird" PHP caching, it doesn't recreate the cache file. I really don't know how it is possible.

[SSoft7]

But if he delete this file, then ruTorrent must to create it again when user reload interface (on getplugins.php call). Why this wasn't happening?
Or he delete this file every time? >:()

Hello,
just wanted to clarify, this is not a permission issue, its a cache issue, I think I have a proper explanation for this.

my web server is configured to cache the mime-type application/javascript so getplugins.php is flagged as javascript type and and it does not refresh with a normal reload. (It's pretty normal to have js files cached)

and rTorrentSettings::get() loads cache when it does not exists. a simple is_readable() check on the cache file before loading the cache file should be enough to solve this.

[Novik]

I understood, thanks.
With such aggressive caching you will have undefined behavior, when

1. you will change plugins set at runtime
2. you will use some plugins (several from them pass current state in the js variables)
3. you will make manual changes in the user's share directory.

[SSoft7]

Thanks for explaining this, I was really interested in knowing what's going wrong. I can see a lot of php files are giving js output so I will just exclude PHP extension from caching.