0 byte files on Webdav

[treynolen]

I had entered an issue earlier (#443) I believe about 0 byte files when using webdav. I was told that there was a caching issue with Netdrive. However, I'm still seeing some issues even when using Cyberduck. I think the issue is triggering the problem with Netdrive. When I upload a file using Cyberduck through Webdav (SSL), the file shows up as 0 bytes. However, another user can download the file and the file is intact. So, it seems that there is an issue where the correct size is not reported. The files I upload ALSO show up in the web interface as 0 bytes, but can be downloaded correctly from there as well. I think Netdrive may be looking at that 0 bytes and just not download the file correctly. I don't get any entries in the owncloud.log, and the apache logs don't report any errors either.

Server - Ubuntu 12.04.1 running OC 4.5.4 on MySQL.

[evert]

As far as I remember NetDrive uses 'extremely aggressive caching', and more or less assumes it's the only client modifying a webdav share. Any changes on the server were for me pretty much ignored until a next connect.

If you are actually seeing a client uploading a file, and then see a real 0-byte file on the server (in the web interface or otherwise) that would be a better starting point.

Question is then if you can isolate the HTTP request that triggers it (using charles HTTP proxy) and upload it somewhere; based on that I will at the very least be able to tell if this is an owncloud issue, or something else.

[karlitschek]

@treynolen: Can you reproduce that with a different client?

[treynolen]

Was just able to do it with BitKinex. Additional information: I mentioned that "another user can download the file..." I'm not sure it was clear that this is working in the Shared folder for the other user.

[leonbollerup]

Hi,

Is there any update on howto resolve this - the only work around i can see is that you need to rename the file after uploading it.. extremely annoying...

[ZinkDifferent]

This problem still exists on OS X 10.8.4 and OC 5.0.10

[joncas]

Hello,

Same problem here, running OS-X 10.8.5, owncloud is the latest version 5.0.12 running in Apache version 2.2.22 with fastcgi on Ubuntu 12.04.2LTS

The "zero bytes available" effectively prevents any file upload via the webdav mount in the Finder.

[karlitschek]

Works fine with OS X 10.9 and ownCloud 6. Please reopen if the problem still exists

[ZinkDifferent]

Will test. If this is now finally fixed, that would be awesome.

__
ceci n'est pas un iPad

On Oct 22, 2013, at 8:01 AM, Frank Karlitschek notifications@github.com wrote:

Works fine with OS X 10.9 and ownCloud 6. Please reopen if the problem still exists

—
Reply to this email directly or view it on GitHub.

[ZinkDifferent]

Where’s the best / current location to download OwnCloud 6?

On Oct 22, 2013, at 8:01 AM, Frank Karlitschek notifications@github.com wrote:

Works fine with OS X 10.9 and ownCloud 6. Please reopen if the problem still exists

—
Reply to this email directly or view it on GitHub.

[DeepDiver1975]

Where’s the best / current location to download OwnCloud 6?

here we go ...
http://mail.kde.org/pipermail/owncloud/2013-October/010875.html

Thanks

[ZinkDifferent]

I can confirm, with beta 1 of OC 6, this problem is indeed gone - you can now upload files via webDAV mounted folders, and they will complete.

BUT:

• uploading a 900KB file over a 20Mbps connection takes 6 minutes.
• the upload leaves the usual .ds_store and ._ds_store file-system files behind on the web view (reported under a separate bug-thread)

1- The slow upload has to do with apache’s lack of support for chunked transfers. The same experiment under an nginx server results in regular speed uploads.

2- There is a fix that was already suggested and provided in one of the threads (#2589), that might be worth reviewing and potentially integrating into 6.

#2589

Without this issue addressed, OC remains a dirty client (and incomplete client) on the Mac OS.

FYI.

On Oct 22, 2013, at 8:01 AM, Frank Karlitschek notifications@github.com wrote:

Works fine with OS X 10.9 and ownCloud 6. Please reopen if the problem still exists

[VanCanuck]

I can confirm this actually is still an issue in OC 6.0. I have 115 0 byte files as of an hour ago. I just did a clean reinstall of OC after having the same problem in December. The reinstall meticulously followed the OC install for Apache/mysql on Centos 6.5. I've had it running for 21 days..and 115 files with no content.

I only use webDav for our staff, not the OC sync clients, nor the web interface.

Fresh CentOS 6.5 running ONLY:
Apache/2.2.15
MySQL version 5.1.71
PHP Version 5.3.3
(all installed from Cent base repos, no third party installs)

Unfortunately I will be moving away from OC as this is a recurring issue and I'm losing data. I would expect this type of issue with core functionality in a beta or RC, not in version 6.0. It's sad as I quite liked the finished product. Nice software!

I wanted to post to let the dev folks know this is a live issue, and definitely restricted to webDav, at least for me. Happy to answer any questions and provide info for as long as the OC server is active, which should be another week or so.

[ZinkDifferent]

On Jan 26, 2014, at 6:53 PM, VanCanuck notifications@github.com wrote:

I can confirm this actually is still an issue in OC 6.0.

Thanks for confirming that this is still an issue. Sad.

FWIW, I have been able to work around it by using OC on an nginx install, instead of Apache, as the issue on Mac OS X and webdav is that OS X uses chunked transfers, which Apache doesn’t support without modifications.

Unfortunately I will be moving away from OC. I would expect this type of issue with core functionality in a beta or RC, not in version 6.0

I do agree with you. The last time this was discussed, the issue degenerated into an idiotic debate about philosophical issues of ‘purity’ (for lack of a better term) than actually dealing with solving it effectively.

This was the previous issue of left-behind files from a Mac client:

• the upload leaves the usual .ds_store and ._ds_store file-system files behind on the web view (reported under a separate bug-thread)

I wanted to post to let the dev folks know this is a live issue, and definitely restricted to webDav, at least for me. Happy to answer any questions and provide info for as long as the OC server is active, which should be another week or so.

It would be nice if effective cross-platform support were finally addressed.

[VanCanuck]

Does OSX use chunk xfer even for small files? this may indeed be a crass platform issue as some of the files I noted are in areas used by OSX clients. All of oour files are <250kb.

Thanks for the info re nginx. Was going to use that for my next setup. However, OC is still painfully slow....again, an issue I wouldn't expect at the level I'm experiencing.

Thanks for the reply, hope it keeps working for you!

[ZinkDifferent]

On Jan 26, 2014, at 7:32 PM, VanCanuck notifications@github.com wrote:

Does OSX use chunk xfer even for small files?

Yes, any size.

this may indeed be a crass platform issue as some of the files I noted are in areas used by OSX clients. All of oour files are <250kb.

Thanks for the info re nginx. Was going to use that for my next setup. However, OC is still painfully slow....again, an issue I wouldn't expect at the level I'm experiencing.

You should notice a significant improvement in performance under nginx.

[anarcat]

this is also an issue web davfs2 FUSE-based clients, as described here:

http://forum.owncloud.org/viewtopic.php?f=8&t=1815
http://sagar.se/owncloud-webdav-zero-filesize.html

[ZinkDifferent]

Reviving this - the performance issue is back under nginx 1.10.0 (w/php7 and Redis cache) -- so, nginx might no longer be the simple solution to fix this, albeit I'm still investigating variables.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.