Bug 10211 - Extension downloader doesn't work with long paths
: Extension downloader doesn't work with long paths
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Plugins
: 7.3.0
: PC Windows XP
: -- normal (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-03 21:03 UTC by Erland Isaksson
Modified: 2008-12-15 09:25 UTC (History)
3 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erland Isaksson 2008-12-03 21:03:08 UTC
There is a problem on Windows when plugins are downloaded with the Extension Downloader and the plugin has long paths to their HTML files. The problem is that this creates paths in the Cache/templates folder that are longer than what Windows XP allows.

In my plugin I have file like this which causes problem:
CustomBrowse\HTML\EN\plugins\CustomBrowse\webadminmethods_newitemparameters.html

In this case it tries to create this file:
C:\Documents and Settings\All Users\Application Data\SqueezeCenter\Cache\templates\C\Documents and Settings\All Users\Application Data\SqueezeCenter\Cache\InstalledPlugins\Plugins\CustomBrowse\HTML\EN\plugins\CustomBrowse\webadminmethods_newitemparameters.html

This is 260 characters, it seems to work if I shorten the file name with one character so the limit seems to be 259 on Windows XP.

The above example has a pretty long filename, but on the other hand the file is in the "EN" skin folder which is shorter than "Fishbone" and it doesn't contain a "settings" directory which many plugins do. So even if I shorten the paths in Custom Browse, we are dangerously close to the limit.

The result can be reproduced by installing the Custom Browse plugin through the Extension Downloader and open up the following page in the web browser:
http://127.0.0.1:9000/plugins/CustomBrowse/webadminmethods_newitemparameters.html?itemtemplate=deepartists.xml

The result is that you will just get a blank page.
Comment 1 Adrian Smith 2008-12-04 11:07:59 UTC
Michael - probably something for you to review - I am not sure if these long file names get used for normal templates used on plugins or just because Erland is using TT himself.  If the forma then we probably need a way to make the path shorter?  I don't see why we need to use the full path of the file to create the cached file.
Comment 2 Erland Isaksson 2008-12-04 11:14:03 UTC
(In reply to comment #1)
> Michael - probably something for you to review - I am not sure if these long
> file names get used for normal templates used on plugins or just because Erland
> is using TT himself.  If the forma then we probably need a way to make the path
> shorter?  I don't see why we need to use the full path of the file to create
> the cached file.
> 

I get the same paths with a plugin that doesn't use TT, so I'm pretty sure it isn't because I use it in my plugin. I've tried to disabled the TT usage in Custom Browse and can reproduce the problem. Just to be sure I also completely uninstalled Custom Browse and I still get files in the Cache/templates directory with similar paths from other plugins.
Comment 3 Adrian Smith 2008-12-04 12:36:36 UTC
This is probably more of a problem on XP as I believe the cachedir is longer on that than Vista (don't have an XP machine to hand but yours is longer)

Looks to me that ED makes this problem ~22 bytes more likely as it inserts an additional "Cache\InstalledPlugins" into the filename, but its a underlying problem with TT and absolutes paths.

A better fix may be to convert the filename to a digest in Template::Provider::_compiled_filename.  (I've not spent a long time looking, but that seems to where the filename is created)
Comment 4 Adrian Smith 2008-12-04 12:53:38 UTC
This probably fixes it Erland:

--- CPAN/Template/Provider.pm   (revision 24200)
+++ CPAN/Template/Provider.pm   (working copy)
@@ -42,6 +42,8 @@
 use File::Basename;
 use File::Spec;
 
+use Digest::MD5 qw(md5_hex);
+
 use constant PREV   => 0;
 use constant NAME   => 1;
 use constant DATA   => 2; 
@@ -581,6 +583,8 @@
     $path =~ /^(.+)$/s or die "invalid filename: $path";
     $path =~ s[:][]g if $^O eq 'MSWin32';
 
+    $path = md5_hex($path);
+
     $compiled = "$path$compext";
     $compiled = File::Spec->catfile($compdir, $compiled) if length $compdir;
 
Not sure what people think about it as a fix though..?
Comment 5 Erland Isaksson 2008-12-04 14:14:23 UTC
(In reply to comment #3)
> Looks to me that ED makes this problem ~22 bytes more likely as it inserts an
> additional "Cache\InstalledPlugins" into the filename, but its a underlying
> problem with TT and absolutes paths.
> 

Just to clarify it's more than 22 characters, the old path was:
C:\Program Files\SqueezeCenter\server\Plugins

While the new is:
C:\Documents and Settings\All Users\Application Data\SqueezeCenter\Cache\InstalledPlugins

This is a 44 character difference compared to before.

This is not just a problem for the Custom Browse plugin, 5 of my 9 plugins have the same problem, all due to a long filename of a html file. Four of them is based on same code as the Custom Browse plugin. In the worst case, with the DatabaseQuery plugin, I think the path gets 7 characters too long.
Comment 6 Adrian Smith 2008-12-04 14:31:50 UTC
Yes - sorry I didn't look at the different prefix.

Alternative fix if we are only out by 7 charcters bytes is to change "InstalledPlugins" to something shorter "Opt" for instance.  Needs changes in the ED plugin itself as it looks for InstalledPlugins.

Michael/Andy - any views (do we have time to change for 7.3)
Comment 7 Michael Herger 2008-12-05 13:58:47 UTC
change 24221 - moving Template/Provider to lib, patching to use md5 hash key instead of full file paths.

Thanks Triode. And sorry for the delay. Meetings keeping us from doing real work ;-)