I'm aware that this project is not being actively maintained, however, reporting this bug and a fix for it may benefit those who are still using this version of the plugin and are looking for a solution.
The problem is, basically, that some operations (archive extract, compress and maybe others) don't have any effect, even though no error is reported. At the moment I've identified the underlying cause affecting the compress archive operation, and I'm looking into why extraction doesn't work.
I'm not an expert in PHP or JS, by far not, but I think I've been able to put together how this plugin works. It's still possible that I've misunderstood/overlooked some points.
Archiving
Short version:
Either set $topDirectory parameter to something that's not an empty string, or skip path = path.split(this.homedir); in init.js / checkinputs() if homedir is empty. Splitting with an empty string does something else than what's intended.
Longer version:
$topDirectory, isn't defined by default.
$topDirectory is used in settings.js.php to set the value of homedir in the JS filemanager class. By default, homedir is an empty string.
Some filemanager operations process input string with init.js / checkinputs(), e.g. archiving and extraction, which
does path = path.split(this.homedir);. As homedir is empty, it just splits it into individual characters, which basically destroys the target path. E.g. if the target path was "/home/download/a.rar" then checkinput() returns "/h". BUG!
Solution:
Setting $topDirectory in conf.php to something not empty (e.g. /home/download if that's where the downloads are). A positive side-effect of this is that one doesn't always need to navigate from / and also provides a little added security. Perhaps this should be included in the default configuration file.
Avoiding splitting the target path if homedir is empty.
Update:
Extraction
This isn't a bug per se, just a problem with permissions. File existence and type related checks in rutorrent's lfp.php (such as is_file, test etc.) use PHP is_file() and similar functions, which don't work properly unless they have read permission on the folder containing the examined file. FileManager uses some of these functions prior to executing operations, e.g. checking for an existence of an archive. This can create problems, however, as FileManager operations run as the rtorrent user (through RPC) and not as the web-server user. If the two users are different, their permissions can also be different, thus some file operations can fail because the file_exist() and is_file() etc. PHP functions fail for the web-server user, even though they would run just fine for the rtorrent user.
Ergo, make sure the web-server user has read permissions on the download folder, or remove the LFS::is_file and similar checks.
Hi,
I'm aware that this project is not being actively maintained, however, reporting this bug and a fix for it may benefit those who are still using this version of the plugin and are looking for a solution.
The problem is, basically, that some operations (archive extract, compress and maybe others) don't have any effect, even though no error is reported. At the moment I've identified the underlying cause affecting the compress archive operation, and I'm looking into why extraction doesn't work.
I'm not an expert in PHP or JS, by far not, but I think I've been able to put together how this plugin works. It's still possible that I've misunderstood/overlooked some points.
Archiving
Short version: Either set $topDirectory parameter to something that's not an empty string, or skip
path = path.split(this.homedir);ininit.js / checkinputs()ifhomediris empty. Splitting with an empty string does something else than what's intended.Longer version:
$topDirectory, isn't defined by default.$topDirectoryis used insettings.js.phpto set the value ofhomedirin the JS filemanager class. By default,homediris an empty string.init.js / checkinputs(), e.g. archiving and extraction, whichpath = path.split(this.homedir);. Ashomediris empty, it just splits it into individual characters, which basically destroys the target path. E.g. if the target path was "/home/download/a.rar" then checkinput() returns "/h". BUG!Solution:
$topDirectoryinconf.phpto something not empty (e.g. /home/download if that's where the downloads are). A positive side-effect of this is that one doesn't always need to navigate from / and also provides a little added security. Perhaps this should be included in the default configuration file.Update:
Extraction
This isn't a bug per se, just a problem with permissions. File existence and type related checks in rutorrent's
lfp.php(such as is_file, test etc.) use PHP is_file() and similar functions, which don't work properly unless they have read permission on the folder containing the examined file. FileManager uses some of these functions prior to executing operations, e.g. checking for an existence of an archive. This can create problems, however, as FileManager operations run as the rtorrent user (through RPC) and not as the web-server user. If the two users are different, their permissions can also be different, thus some file operations can fail because the file_exist() and is_file() etc. PHP functions fail for the web-server user, even though they would run just fine for the rtorrent user.Ergo, make sure the web-server user has read permissions on the download folder, or remove the LFS::is_file and similar checks.