hello
in fact it's not really an issue because it was initially done to prevent incompatibility url ; utf8 was not a standard
but when you say

If the filename contains a space

did you allow that character in $conf['sync_chars_regex'] ?

as i wrote part of the problem is that i.php verifies the request url directly against "$conf['sync_chars_regex']" which is a problem because spaces and umlauts are escaped in the request.
Just for testing purpose i changed line 202 to

foreach (preg_split('#/+#', rawurldecode($req)) as $token)

hence adding the rawurldecode call.
Like that the "Invalid chars in request" message wont appear anymore assuming the characters were correctly added to $conf['sync_chars_regex']  .

still the thumbnails won't be showed, because they never got  created.
I guess there is a similar error in the thumbnail creqting function. Propably using the still urlencoded picture path as argument.
I will look into that once I find an usable computer... ;-)

ok, i got as far as I could by only using a text editor over an ssh connection...
The error seems to be all in the file i.php (at least all the ones I found so far).
In the array $page the paths to the pictures are stored as urlencoded strings.That means any function accessing the filesystem can't find the path
e.g.

@filemtime($page['src_path']);   // about line 402
@filemtime($page['derivative_path']); //about line 410

This happens at several places in the code (my line number from above are maybe not absolut exact anymore, since I did a lot of editing of the code for debugging purpose...).
Each time the variable should be deencoded using the rawurldecode function:

rawurldecode($page['src_path'])

Or what propably would be a lot better is to directly store the paths in the variable as unencoded string, and only encode them, when it is used to generate html links to the files.

Additionaly there is a problem in about line 455

SELECT *
  FROM '.$prefixeTable.'image
  WHERE path=\''.$page['src_location'].'\'

Again the rawurldecode is missing, and additionally there should be set a "./" in front of the path since that's the way it is stored in the database (I don't know how that query in the actual form ever worked anyway):

SELECT *
  FROM '.$prefixeTable.'images
  WHERE path=\'./'.rawurldecode($page['src_location']).'\'

I somehow managed that it acidentaly created some thumbnails using the batchmanager to debug (the filenames had %20 and similarstuff in it) but it still doesn't work correctly, but I just don't wanna continue debuging this way...
But I think you get the general picture, and I think for the developpers, especially with a real debugging environment it should be quite easy to fix that...
Just make a decision if in general you want to store path names in the variables as the real path names (good practice in my opinion) and only encode them, if used for html output (this already seems to be the case anyway, since they are stored unencoded in the database, but the gallery pages generated contain them in the encoded form), or if you really want to already store them encoded, and each time you access the filesystem want to decode them.


It can be that for the synchronization function the errors are at an other place in the code, but it was just a lot easier for me to use the batchmanager, since like that I only needed to reload the page instead of renaming files all the time... But I guess it will be similar errors there (even I can not see any reason you should get encoded strings when you're only working on the filesystem level).

Last edited by RMM (2012-07-10 18:46:02)

I created a patch and attached it to the bug report http://piwigo.org/bugs/view.php?id=2686
I post that also here since I never got any reaction to my bug report ;-).
Would be great if it could be incorporated into 2.4.4
like that the new $conf['sync_chars_regex']-feature finally would make some sense (at least for linux users... see bug report)