New beta plugin: WebDAV (WebFolders)

[Lefteous]

2ghisler(Author)

I received the following error while counting the directory contents size:

---------------------------
Total Commander
---------------------------
Access violation at address 00EE11AA. Read of address 01EDD000.
Please report this error to the Author,
with a description of what you were doing when this error occured!
Continue execution?
---------------------------
Ja Nein
---------------------------

After the first unsuccessfull attempt the second was just fine.

[Horst.Epp]

2ghisler(Author)

I am able to delete remote files, but I cannot overwrite files. Any ideas? Is it a rights problem or a problem of the plugin?
The current inability to overwrite files makes synchronizing a two step operation. Delete the remote files first and then transfer the local files to the server.

Its a plugin problem.
I tried it with my 1und1 account getting the same error.

[ghisler(Author)]

I cannot reproduce this, overwriting works just fine. Can you check the detailed log option, and post a log here please?

[Lefteous]

2ghisler(Author)

I cannot reproduce this, overwriting works just fine. Can you check the detailed log option, and post a log here please?

Ein paar Zusatzinfos noch:
es wird angezeigt, dass die zu überschreibenden Datei auf dem Server 1 byte groß ist. Das ist aber falsch!

Als Fehler wird angezeigt: Fehler beim Herunterladen! JavaClock.java

Code: Select all

CONNECT \1 und 1
Get dir: \Test
PROPFIND /Test/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset="utf-8"
User-Agent: ezdavplugin
Host: mediacenter.1und1.de
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
******Received headers
HTTP/1.1 207 Multi-Status
Date: Mon, 26 Apr 2004 19:07:01 GMT
Server: Apache
MS-Author-Via: DAV
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"
207 Multi-Status
Get dir: \Test\
PROPFIND /Test/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset="utf-8"
User-Agent: ezdavplugin
Host: mediacenter.1und1.de
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
******Received headers
HTTP/1.1 207 Multi-Status
Date: Mon, 26 Apr 2004 19:07:06 GMT
Server: Apache
MS-Author-Via: DAV
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"
207 Multi-Status
File send: \Test\JavaClock.java
First upload step: Send 1 byte file for authentication
PUT /Test/JavaClock.java HTTP/1.1
Content-Type: application/octet-stream
User-Agent: ezdavplugin
Host: mediacenter.1und1.de
Content-Length: 1
Connection: Keep-Alive
Pragma: no-cache
******Received headers
HTTP/1.1 204 No Content
Date: Mon, 26 Apr 2004 19:07:08 GMT
Server: Apache
MS-Author-Via: DAV
Connection: close
Content-Type: text/plain
204 No Content
Last upload step: Send actual file
Get dir: \Test
PROPFIND /Test/ HTTP/1.1
Depth: 1
Content-Type: text/xml; charset="utf-8"
User-Agent: ezdavplugin
Host: mediacenter.1und1.de
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
******Received headers
HTTP/1.1 207 Multi-Status
Date: Mon, 26 Apr 2004 19:07:10 GMT
Server: Apache
MS-Author-Via: DAV
Connection: close
Transfer-Encoding: chunked
Content-Type: text/xml; charset="utf-8"
207 Multi-Status

[ghisler(Author)]

Sollte eigentlich gehen - bitte mal die Option "Use 3 step upload method" probieren, das ist bei einigen Servern nötig.

[Lefteous]

2ghisler(Author)

Sollte eigentlich gehen - bitte mal die Option "Use 3 step upload method" probieren, das ist bei einigen Servern nötig.

Das scheint mir leider nicht die Lösung zu sein. Der Upload klappt jetzt, jedoch ist die Datei auf dem Server nur 2 bytes groß. Es sind dies die ersten beiden Zeichen der lokalen Datei - der Rest fehlt aber. Es scheint hier jedoch keinen Zusammenhang zum Überschreiben zu geben. Die 3-step Methode hat bei jedem Upload dieses Ergebnis. Wenn keine gleichnamige Zieldatei vorhanden ist erscheint hierbei eine Fehlermeldung. Ist eine gleichnamige Zieldatei schon vorhanden, gibt es keine Fehlermeldung - das war eingangs mit "der Upload klappt jetzt" gemeint. Ich kann aber nur davor warnen.

Wie mir gerade auffällt ist die überschriebene Remotedatei genau 1 byte groß, wenn ich, wie üblich, die 3-Step Methode deaktiviert habe.

[Horst.Epp]

Sollte eigentlich gehen - bitte mal die Option "Use 3 step upload method" probieren, das ist bei einigen Servern nötig.

Damit geht es bei 1und1 nicht.
Es kommt eine 1 Byte Datei und ein Fehler heraus.
1und1 benutzt Apache.

[ghisler(Author)]

Tja, dann ist mein Plugin mit 1&1 leider nicht kompatibel.

Keine Ahnung was die für eine Apache-Version benutzen, bei mir unter Linux funktioniert sowohl die 2- wie die 3-Schritt Methode einwandfrei. Das Plugin schickt im 1. Schritt nur 1 Byte der Datei, was in den meisten Fällen mit einem Fehler beantwortet wird (Authorization required oder so). Würde das plugin die ganze Datei schicken, müsste es die gleichen Daten 2x hochladen, was natürlich hochgradig ineffizient wäre.

Leider habe ich keinen Zugang auf einen 1&1-Server, so dass ich nur von der Benutzung des Plugins mit 1&1 abraten kann. Bei GMX geht es übrigens problemlos.

Vielleicht kann sich ja ein Programmierer mit 1&1-Zugang des Problems annehmen...

[kwirk]

@ghisler

Hello Christian,

plugin works fine with Netscape/Livelink WEBDAV-Server.

Just two points:
- problem during Synchronisation: the Time differs by three hours.
- why have i to enter password with every connect - why not saved?

thnxs for answer
kwirk

[fnheiden]

Tja, dann ist mein Plugin mit 1&1 leider nicht kompatibel.

[..]

Leider habe ich keinen Zugang auf einen 1&1-Server, so dass ich nur von der Benutzung des Plugins mit 1&1 abraten kann. Bei GMX geht es übrigens problemlos.

Vielleicht kann sich ja ein Programmierer mit 1&1-Zugang des Problems annehmen...

I think a simple DELETE before the PUT would fix these problems in FsPutFile:

Code: Select all

if (OverWrite && !Resume) {
  WebDavDeleteFile(serverid, remotedir);
}

Best regards,
~ Florian

[ghisler(Author)]

Unfortunately a delete wouldn't help - it's not the actual upload which fails, it's the Web server ignoring the file size field in the second upload step.

To explain why the plugin has to use multiple upload steps:
1. The plugin tries to send a file
2. The server replies with "authentication needed"
3. The plugin sends the file again with the necessary authentication

To avoid that the entire file (which may be HUGE) will be sent twice, the plugin only sends a 1 byte file on the first try, and the entire file only on the second try. The plugin does send the correct file size both times, but apparently the 1&1 server ignores the file size on the second try.

I don't think that I can get this to work without access to an 1&1 server. Perhaps someone is willing to give me temporarily access to his account?

[fnheiden]

I don't think that I can get this to work without access to an 1&1 server. Perhaps someone is willing to give me temporarily access to his account?

Feel free to contact me, I'll give you access to my account.

Best regards,
~ Florian

[ghisler(Author)]

Thanks for your offer! I have jsut sent you an e-mail via the board.

[fnheiden]

Thanks for your offer! I have jsut sent you an e-mail via the board.

I've just sent you the account information.

BTW: I locally changed the source code of the plugin to delete the existing file before uploading and it works quite well.

Best regards,
~ Florian

[fnheiden]

Updated plugin is working fine with 1und1 now.

~ Florian