Closed GoogleCodeExporter closed 9 years ago
Yes, last version changed the session management, and this was broken. I made
some further changes that requires new version 1.8.7.1, and WebDAV 1.7. I've
marked them deprecated until it has been tested, if you test it could you let
me know how it works.
http://code.google.com/p/mollify/downloads/detail?name=mollify_1.8.7.1.zip
http://code.google.com/p/mollify/downloads/detail?name=plugin_webdav_1.7.zip
Original comment by samuli.j...@gmail.com
on 5 Mar 2012 at 6:12
Hi Samuli,
thanks for your quick help: Ich tested the version and authentication worked
again with the new webdav plugin.
I tested the webdav interface using my android phone and "webdav file manager".
The download worked too, but (not sure if this is related to the plugin or
mollify) upload really uploads the data, but results in zero byte files with
the correct name.
Do you have an idea where to have a look for possible reasons?
Thank you and best regards,
Markus
Original comment by recht...@dotquality.de
on 5 Mar 2012 at 8:02
I've tested WebDAV with CyberDuck, and it works.
Usually zero byte downloads are caused by invalid chars in PHP files etc, but
haven't seen this with WebDAV. If you enable debug logging, is there anything
in the logs?
Original comment by samuli.j...@gmail.com
on 5 Mar 2012 at 9:27
Good Morning,
the mollify log says nothing unfortunately - using the web interface it logs as
expected - using the webdav interface nothing is logged. Is there a switch I am
missing besides these setting?
"debug" => TRUE,
"debug_log" => "/srv/tmp/mollify.log",
Thank you!
Markus
Original comment by recht...@dotquality.de
on 6 Mar 2012 at 7:57
I just tried uploading using BitKinex which resulted in zero byte files too.
CarotDav gave mit an exception (not sure if this is related to the same problem)
The test with my phone of course did not involve a proxy server - both clients
above were used from work (behind a companies proxy) ...
The error given was:
The remote server returned an error: (417) Expectation failed.
Original comment by recht...@dotquality.de
on 6 Mar 2012 at 8:27
I did another test to ensure that the proxy is not (again) the problem.
With "cadaver" commandline interface from another server of the same provider -
so no proxy here..
dav:/mollify/backend/dav/markus/> put tmp_bk_sp
Uploading tmp_bk_sp to `/mollify/backend/dav/markus/tmp_bk_sp':
Progress: [=============================>] 100.0% of 7 bytes succeeded.
Again it looks like everything went right, but the result is zero bytes :-/
Which is quite interesting is that this time a filesystem event occured which
caused a notification mail to be sent.. only this time, not for the previous
tests.
Original comment by recht...@dotquality.de
on 6 Mar 2012 at 8:43
Sorry, I didn't notice you were talking about upload, I thought it was about
download.
Yes, I can see the problem as well, upload results in 0 b. I'll look into this
as well.
Original comment by samuli.j...@gmail.com
on 6 Mar 2012 at 11:13
I found the error, the content was consumed when trying to parse it as JSON.
Get the packages again with the links I posted earlier, the names are same but
the have been rebuilt.
Original comment by samuli.j...@gmail.com
on 6 Mar 2012 at 11:27
Hi, indeed upload works again.
Hopefully it's not related to our companies proxy (caching stuff) but when
logging in by web interface I get the listing of all "root" folder and when I
try to enter one folder I get:
Protocol error
Got malformed JSON response:
Fatal error: Cannot access private property Request::$data in
/var/www/htdocs/mollify/backend/include/services/FilesystemServices.class.php
on line 330
I'll give it another try at home ...without proxy to be sure!
Thank you,
Markus
Original comment by recht...@dotquality.de
on 6 Mar 2012 at 11:38
Yes, sorry. I was too hasty about the fix, and did not try the regular client.
I already uploaded new copy of the 1.8.7.1.
Original comment by samuli.j...@gmail.com
on 6 Mar 2012 at 11:40
Yep, now working again!
Thank you, Samuli
Original comment by recht...@dotquality.de
on 6 Mar 2012 at 12:02
Original issue reported on code.google.com by
recht...@dotquality.de
on 5 Mar 2012 at 9:23