s9y_200502151337 -> Image Uploading Directory Bug

[tmontague]

In s9y_200502151337 from yesturday, When you go to upload an image / file the upload directory is missing a '/' which is causing the image/file name to become the directory + filename. Example->

Code: Select all

You have the Uploads directory to begin with. Then you add Images and Files directories with s9y. You go to upload an image named "test.jpg" to uploads/images/ by selecting images in the "Store inside the following directory:" dropdown list. You then upload the file and the results page afterwards show that the file what uploaded to "...../uploads/imagestest.jpg" and not to "..../uploads/images/test.jpg"

I know this is a minor problem but it is easily as the problem is in the targetDirectory Post varible usage. Thanks,
Thomas

[garvinhicking]

Can you please try todays snapshot? We fixed a bug there just yesterday.

(replacing include/functions_images.inc.php and include/admin/images.inc.php should do)

Regards,
Garvin

[tmontague]

I will try the new cvs later today, Thanks.

Thomas

[tmontague]

Yesturday I downloaded s9y_200502161337 and it still contained that same problem as before.

[garvinhicking]

Strange, it works here on my system.

Can you please tell me your configuration directives for:

* serendipityPath
* uploadPath
* serendipityHTTPPath
* uploadHTTPPath
* baseURL

(See Configuration, group "Path settings").

And please have a look at the HTML sourcecode of the page were you upload the picture file, there were you can see the dropdown to choose your directory. In the HTML Code you should see code like this:

Code: Select all

<tr>
    <td>Store inside the following directory: </td>
    <td>
        <select name="serendipity[target_directory]">
        <option value="">Base directory</option>
        <option  value="temp/">   temp</option>
        <option  value="temp/cool/">     cool</option>
        <option  value="temp/fool/">     fool</option>
        <option  value="temp//fool/mool/">       mool</option>
        <option  value="temp/bool/">     bool</option>
        </select>
    </td>
</tr>

As you can see in my option value="" tag there's always a trailing slash.

How do you upload the file? Via URL or via Browser file upload? And do you enter anything into the input field "Save the file as:"?

Thanks,
Garvin

[tmontague]

I am running it on a home testing server running Win Server 2003 with Apache 2.0.5, PHP 5.0, and MySQL 4.0.20. I'm using the domain name lmbbox.local which is running off of my Win Server 2003's DNS/Active Directory. Here are the Path settings:

Full Path: -> C:/WebServer/root/html_root/blog2/
Uploads Path: -> uploads/
Relative Path: -> /blog2/
Relative Template Path: -> templates/
Relative Uploads Path: -> uploads/
URL Path: -> http://lmbbox.local/blog2/
Index File: -> index.php

This is the source html from the add media page where the select directory dropdown list is:

Code: Select all

<td>Store inside the following directory: </td>
                    <td>
                        <select name="serendipity[target_directory]">
                        <option value="">Base directory</option>

                                                <option  value="images\">   images</option>
                                                </select>
                    </td>

I upload the file/image using the brower upload file option. As for the filename, it uses the default filename that is generated. If you can't figure it out, I will upload the latest cvs to my hosting server and try it on there. It's a LAMP installed server with WHM/Cpanel.

Thomas

[garvinhicking]

Okay, thanks for your detailed answer! Thanks to this it was easy to figure out the error, which is because serendipity is using the "\" as path seperator instead of "/".

Could you please apply this DIFF to your actual serendipity install please:

Code: Select all

Index: include/functions_images.inc.php
===================================================================
RCS file: /cvsroot/php-blog/serendipity/include/functions_images.inc.php,v
retrieving revision 1.33
diff -u -r1.33 functions_images.inc.php
--- include/functions_images.inc.php    15 Feb 2005 23:34:45 -0000      1.33
+++ include/functions_images.inc.php    17 Feb 2005 16:20:30 -0000
@@ -1077,7 +1077,15 @@
                if ( $file != '.' && $file != '..' ) {
                        if ( $onlyDirs === true && is_dir($basedir . DIRECTORY_SEPARATOR . $dir . DIRECTORY_SEPARATOR . $file) ) {
                 if ( is_null($pattern) || preg_match($pattern, $file) ) {
-                               $files[] = array('name' => $file, 'depth' => $depth, 'relpath' => ltrim($dir, DIRECTORY_SEPARATOR) . basename($file) . DIRECTORY_SEPARATOR);
+                               $files[] = array(
+                        'name'    => $file,
+                        'depth'   => $depth,
+                        'relpath' => str_replace(
+                            DIRECTORY_SEPARATOR,
+                            '/',
+                            ltrim($dir, DIRECTORY_SEPARATOR) . basename($file) . DIRECTORY_SEPARATOR
+                        )
+                    );
                 }
                        }
             if ( is_dir($basedir . DIRECTORY_SEPARATOR . $dir . DIRECTORY_SEPARATOR . $file) ) {

(If you can't read the diff properly - you need to change the line

Code: Select all

'relpath' => ltrim($dir, DIRECTORY_SEPARATOR) . basename($file) . DIRECTORY_SEPARATOR

to

Code: Select all

'relpath' => str_replace(DIRECTORY_SEPARATOR, '/', ltrim($dir, DIRECTORY_SEPARATOR) . basename($file) . DIRECTORY_SEPARATOR)

This way the output of a path structure with mixed \-style windows paths and /-style unix paths always results in "/"-style unix paths. That is compatible with windows environments...

Regards,
Garvin

[tmontague]

Ok that's great! Thanks. I just wanted to make sure that you caught that and fixed it for other releases. Because I know that in s9y 0.7.1, this problem doesn't exist on either Windows or Unix. Thanks again,

Thomas

[garvinhicking]

So does the fix work on your 0.8 installation? Then I will commit the fix...

IF you have the chance it would be creat if you could test if deleting and browsing directories works properly on your windows machine (I don't have a windows install at hand currently)

Regards,
Garvin

[tmontague]

I inserted the code into includes/functions_images.inc.php and it corrected the original problem with the image upload and directory problem. I tested the creatiation of directories and deletation of them as well and that ran smothly on my Win Server 2003 machine. The only problem that I came across is the "Rebuild Thumbnails" function! Here is what happens:

If you have any images/files in any directory(ies) that's not the "Base Directory" you get this error if the image has a thumb: ->
Unable to locate the file entitled images\images\image_246.jpg, maybe it has already been deleted?

And this error if the image doesn't have a thumb: ->
Wanted to use images/image_246.jpg as it's own thumbnail, but failed to copy!
Unable to locate the file entitled images\images\image_246.jpg, maybe it has already been deleted?

As you can see, the problem is that the directory is listed twice causing that path to be incorrect! This wasn't a problem if the image/file is in the "Base Directory."

Thomas

[Thomas]

Hi,

today I upgraded my local installation on a WinXP machine to the latest available snapshot from today and saw that the media database didn't display any images anymore. As content in the articles the output was alright (except the design but that's normal I think when using a 0.7.x design in 0.8 that it is screwed up).
Anyway, for some reason the first path information was allright but for the serendipity-manages directories (everything below '/uploads') had backslashes instead of usual slashes.
Example: /uploads/path\to\other\dir.

First I thought the fix from this thread might bring the solution which was not the case, unfortunatly.

Investigating the problem I found out that for some reason the path information in the table serendipity_images was incorrect. I found the backslashes there.

I fixed it with following DDL statement using the SQL execution window from phpMyAdmin:

Code: Select all

update serendipity_images set path = replace (path, '\\', '/');

Then the display works fine again in the media database. I think this might be an important information specially for those using s9y on a windows machine. Currently I was not able to figure out if this happened when I first started s9y in version 0.7.1 or if it happened during the upgrade.

Regards, Thomas

[Thomas]

BTW, 1 minute ago I figured out that the same thing happens also when managing directories.
I created successfully a sub directory under some other directory but deleting was not possible because there I see again the double slashes like "pix//2005//02/test/ " (example from my existing local installation).

Again, some minutes (or hours?) of investigation took me to line ~1089:

Code: Select all

                $files = array_merge($files, serendipity_traversePath($basedir, $dir . DIRECTORY_SEPARATOR .  basename($file) . DIRECTORY_SEPARATOR, $onlyDirs, $pattern, ($depth+1)));

After that line I added a print_r($files) output to see what happens. Curious was that if the traversing has gone into depth it starts to add the second slash:

Code: Select all

    [5] => Array
        (
            [name] => funpix
            [depth] => 1
            [relpath] => funpix/
        )

    [6] => Array
        (
            [name] => 2005
            [depth] => 2
            [relpath] => funpix/2005/
        )

    [7] => Array
        (
            [name] => 02
            [depth] => 3
            [relpath] => funpix//2005/02/
        )

I though one slash is enough and changed the line to:

Code: Select all

                $files = array_merge($files, serendipity_traversePath($basedir, $dir . basename($file) . DIRECTORY_SEPARATOR, $onlyDirs, $pattern, ($depth+1)));

And for now the display is correct:

Code: Select all

    [5] => Array
        (
            [name] => funpix
            [depth] => 1
            [relpath] => funpix/
        )

    [6] => Array
        (
            [name] => 2005
            [depth] => 2
            [relpath] => funpix/2005/
        )

    [7] => Array
        (
            [name] => 02
            [depth] => 3
            [relpath] => funpix/2005/02/
        )

And, last but not least get rid of the trailing slash at line 1084:

Code: Select all

                        'relpath' => str_replace(DIRECTORY_SEPARATOR, '/', ltrim($dir, DIRECTORY_SEPARATOR) . basename($file) )

The wished result:

Code: Select all

    [3] => Array
        (
            [name] => funpix
            [depth] => 1
            [relpath] => funpix
        )

    [4] => Array
        (
            [name] => 2005
            [depth] => 2
            [relpath] => funpix/2005
        )

    [5] => Array
        (
            [name] => 02
            [depth] => 3
            [relpath] => funpix/2005/02
        )

That is needed that the rmdir works properly.
Now because basically it does not work right now I investigated the code a bit more and found out that there's a problem.
You open the directory $directory in function serendipity_killPath but you do not close it before you try to delete the directory. That's causing a "Permission denied" error because of the open handle.
Solution for this is easy.

Code: Select all

...
        } // <-- Add this here to close the very first if, linenr. ~1053
        closedir($handle); // <-- needed for closing the handle

     echo '<strong>';
     if ($serious && !empty($directory) && !preg_match('@^.?/?$@', $directory) && @rmdir($basedir . $directory)) {
         printf(DIRECTORY_DELETE_SUCCESS . $n, $directory);
     } else {
         printf(DIRECTORY_DELETE_FAILED . $n, $directory);
     }
     echo '</strong>';
      // } <-- original end of the first if
...

That's all. I hope the desciption is useful. The directory handling works now (at least for me) with those fixes.

Regards, Thomas

[Pedda]

If you have any images/files in any directory(ies) that's not the "Base Directory" you get this error if the image has a thumb: ->
Unable to locate the file entitled images\images\image_246.jpg, maybe it has already been deleted?

And this error if the image doesn't have a thumb: ->
Wanted to use images/image_246.jpg as it's own thumbnail, but failed to copy!
Unable to locate the file entitled images\images\image_246.jpg, maybe it has already been deleted?

As you can see, the problem is that the directory is listed twice causing that path to be incorrect! This wasn't a problem if the image/file is in the "Base Directory."

Thomas

This bug still exists in the snapshot 200502241337 I've downloaded yesterday evening.

[garvinhicking]

Thanks a lot. I will review this information and try to patch Serendipity the next week with this.

Regards,
Garvin.

[Pedda]

I've just updated to 0.8-beta1 on PHP 4.3.9-1 and what I've seen is that the bug has changed a little bit...

If I copy a .jpg-file into the upload directory on the server and run a "Rebuild Thumbs" the new image is detected correctly. But if I copy the file into a subdirectory of upload the image is not detected at all.

Unfortunately I'm not good enough in PHP programming to have a look at the sources...

Regards, Pedda