Error -300 IO Error, when uploading many files at once

[GoogleCodeExporter]

I'm having this small problem when uploading a lot of files at once.
For example 20 picture files and at some point randomly i get "Error: -300, 
Message: IO error., File: IMGP5339.JPG" and the uploading will hang. I found 
nothing in the error-log and I'm using plupload plugin, perhaps the issue lies 
in the plupload plugin itself. When the "error-file" appears and which causes 
the error -300, then the file is copied to the temp directory and it stays 
there, but not to the correct location under user folders. Perhaps there is 
some problem when plupload plugin tries to move the file to the correct 
location from temp directory?

Ohh and small note:
Under: .\backend\plugin\Plupload\PluploadHandler.class.php
And around line 42 i used:
$fileName = preg_replace("/[\47\92\34\39]+/", "", $fileName);
instead of the original one which had "x" included in there, the original one 
didn't work and cut off file extensions. For example "JPG" was cut down to "JP" 
when uploading.
I know it's weird and the original one should work as well, but for some reason 
it didn't and i used the temporary fix "$fileName = 
preg_replace("/[\47\92\34\39]+/", "", $fileName);" you gave me a while ago, 
that one works fine.

Original issue reported on code.google.com by Logic...@gmail.com on 29 Jan 2012 at 2:01

[GoogleCodeExporter]

Actually, the latest plupload plugin has (yet) another version of the regex, 
it's like this:

$fileName = preg_replace("/[\\x2f\\x5c\\x22\\x27]+/", "", $fileName);

It's weird that PHP error log should not have anything, are you sure your PHP 
has logging enabled?

Original comment by samuli.j...@gmail.com on 29 Jan 2012 at 2:08

[GoogleCodeExporter]

This is weird, i replaced the old regex with the one you gave me here and now 
it stood up longer before throwing the error at me. Anyway i couldn't figure 
out what else to enable to get PHP error logs, so i pretty much enabled all 
logging everywhere i possibly could. Things are really slow, but hey, it 
worked, i got the error log.
This error log is taken from the moment when the "error-file" (which throws the 
error and the file is pretty much random every time) got to the mollify's 
processing list, here it is, hopefully it helps:

[29-Jan-2012 14:19:34 UTC] MOLLIFY DEBUG: Upload temp dir: 
C:\Users\Apache\AppData\Local\Temp

[29-Jan-2012 14:19:34 UTC] MOLLIFY DEBUG: Uploading to 
C:\Users\Apache\AppData\Local\Temp\IMGP5373.JPG (2/4)

[29-Jan-2012 14:19:34 UTC] MOLLIFY DEBUG: Content type: multipart/form-data; 
boundary=----pluploadboundary1327846773381

[29-Jan-2012 14:19:35 UTC] MOLLIFY DEBUG: MySQL DB: 
mollify@localhost:mollify(mollify_) port= socket=

[29-Jan-2012 14:19:35 UTC] MOLLIFY DEBUG: EVENT HANDLER: registering 
'filesystem/': ShareHandler

[29-Jan-2012 14:19:35 UTC] MOLLIFY ERROR: PHP error #8, session_start(): 
ps_files_cleanup_dir: opendir(C:\Windows\Temp) failed: No such file or 
directory (2) (C:\EWUL 
SERVER\Apache\OTHER\CLOUD\backend\include\Session.class.php:37)

[29-Jan-2012 14:19:35 UTC] MOLLIFY DEBUG: RESPONSE error {0:999, 1:Unexpected 
server error, 2:500} PHP error #8, session_start(): ps_files_cleanup_dir: 
opendir(C:\Windows\Temp) failed: No such file or directory (2) (C:\EWUL 
SERVER\Apache\OTHER\CLOUD\backend\include\Session.class.php:37)

Also, the JPG file is in the "Apache" user temp directory and it's there 
partially, meaning that the error -300 can and did come in the middle of the 
file upload process.

By the way, i have no idea whats with the timestamps, it shows 2 hours earlier 
than it should, even tho I'm in the same timezone as you are. Never mind, off 
topic.

Original comment by Logic...@gmail.com on 29 Jan 2012 at 2:28

[GoogleCodeExporter]

The error seems to be related PHP garbage collection, this post is about the 
same issue: 
http://forum.kohanaframework.org/discussion/565/garbage-collector-error-with-ses
sions-on-debian/p1

Could you check if you have garbage collection on, and try turning it off?

Original comment by samuli.j...@gmail.com on 29 Jan 2012 at 4:25

[GoogleCodeExporter]

Yes, i have the garbage collection on. In order to turn it off i needed to 
change "php.ini" from the value:
"session.gc_probability = 1"
to the value:
"session.gc_probability = 0"

That doesn't turn it exactly off, but it reduces the probability of the garbage 
collection event to happen to 0%.

I tested this and i now uploaded 243 JPG files without problems and errors.

But i am slightly concerned about the fact that i do have other scripts running 
in the server and garbage collection is basically a memory management event. 
Now it's turned off. I'm worried that perhaps garbage collection is needed for 
memory leaks etc and my other scripts perhaps might suffer because of it.
Could Mollify perhaps get a workaround for this, so garbage collection wouldn't 
annoy Mollify?

I read from google that garbage collection is a pretty good thing to have on a 
server.

Original comment by Logic...@gmail.com on 29 Jan 2012 at 4:51

[GoogleCodeExporter]

For what I understood, this is a PHP bug: 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626640 and so this primarily 
needs to be fixed in PHP.

I don't want to make any dirty hacks, but of course if there is some "clean" 
modification that wouldn't break anything else, I can do that.

Could you try changing "include/Session.class.php" line 37 by adding @ in front 
of the command, ie "session_start..." -> "@session_start". This is the only 
concrete workaround I could quickly see mentioned, and unless this works, I'm 
not sure what to do.

However, this is not the only problem PHP session brings, and I have plans in 
removing the need for it. But of course this takes some time.

Original comment by samuli.j...@gmail.com on 29 Jan 2012 at 5:58

[GoogleCodeExporter]

I'll stick with the current fix you offered, by disabling garbage collection. 
If it causes some further problems, I'll let you know.

What did you mean by your last sentence though? Do you mean there are more bugs 
in Mollify that might pop up some day and are caused by garbage collection or 
PHP session?

Original comment by Logic...@gmail.com on 29 Jan 2012 at 6:47

[GoogleCodeExporter]

So adding @ did not make any difference?

Like I said, I don't consider this Mollify bug at all, because nothing 
indicates that there is anything to be done differently (except the one 
suggestion I mentioned, and even it does not make any sense) in Plupload or 
Mollify in general regarding this issue.

With the problems I referred, I'm talking about unnecessary limitations and 
side-effects PHP session brings. For example, when PHP sessions are used, it is 
not possible to handle simultaneous requests within one session, because the 
session file is locked. And to begin with, I wouldn't want cookies to be used 
at all, because it is too persistent, and PHP session concept is meant for 
storing something, while Mollify needs not to persist anything. Also multiple 
instances in one server needs hacks like session name prefix. Simple "own made" 
auth key + HTTP headers should be enough when client authenticates itself, and 
this way it is clear what instance is the auth key for. Probably also would be 
faster, since PHP uses file to store sessions. And so on...

Original comment by samuli.j...@gmail.com on 29 Jan 2012 at 7:01

[GoogleCodeExporter]

Actually, the problem seems to be in debian side, this report explains the 
situation quite well: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/619855

In a nutshell, due to the way session files and their permissions are handled 
in debian, garbage collection used to be disabled in debian, but debian 
packaging has broken this.

The discussion points out that disabling gc is indeed not wise in some cases 
(large sessions), but it really seems there is nothing to be done, except maybe 
change the way how debian itself cleans the files (which is of course out of 
any PHP script scope).

Naturally, if someone can point out any kind of fix for this in PHP script 
side, I'll gladly consider it.

Original comment by samuli.j...@gmail.com on 29 Jan 2012 at 7:27

[GoogleCodeExporter]

Sorry for the late response, i was tired yesterday and went to bed.
No, i didn't try the adding "@" sign method, i have this thing, trying to avoid 
"hacks" as much as possible, have a bad history with them.

About the "large sessions" I'm really not clear about what they mean. Does it 
mean a session as in i.e someone is logged in via mollify? The longer the 
person is logged in that way, the longer the session, therefore "large 
session"? Or does it mean "large" as in a lot of traffic? What is the security 
issue here?
Anyway, not that important, no need to answer to the last one.

I'll keep my GC disabled, if i find any problems with it later in the future, 
I'll let you know.
Wish you the best at developing Mollify!

Original comment by Logic...@gmail.com on 30 Jan 2012 at 6:30

[GoogleCodeExporter]

Don't worry, not that urgent :)

Like I said before, adding @ does not make any sense, because it only hides any 
possible error message, but the error still happens. So it won't probably help 
at all.

I know what you mean with the hacks, I don't like them any more than you do.

For the large sessions, it means large sessions in content. Mollify is nothing 
to worry about as it does not store much data, but some other script might. 
However, I'm not sure how would you check this.

Original comment by samuli.j...@gmail.com on 30 Jan 2012 at 6:50

[GoogleCodeExporter]

Forgot to update this issue, Mollify don't use PHP sessions anymore. Can you 
check if this is fixed?

Original comment by samuli.j...@gmail.com on 19 May 2012 at 11:21

[GoogleCodeExporter]

It should be fixed yes, i disabled the PHP garbage collection as well. But I'm 
pretty sure it's working even with that enabled.

By the way, what method are you using now?

Original comment by Logic...@gmail.com on 19 May 2012 at 11:58

[GoogleCodeExporter]

I created own session handling, storing session data into Mollify database.

Original comment by samuli.j...@gmail.com on 19 May 2012 at 12:02

• Changed state: Fixed