maindavfs2 - Support: sr #109073, All Files on webdav share are...

 
 

sr #109073: All Files on webdav share are downloaded after mount

Submitter:  Michael <michaelof>
Submitted:  Tue 21 Jun 2016 09:27:53 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  5 - Blocker Status:  Duplicate
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 23 Jun 2016 01:23:26 AM UTC, comment #3: 

Ok just checked after a new mount. "ls" don't trigger, KDE's Dolphin file manager triggers. You're right.

But only when Dolphin should "show" a davfs2-mounted share. If the same share is accessed by Dolphin's "webdavs://user@host:port/ linking "ls", it works fine. (Uploads not, that's why I'm now using dafs2, but read access works fine and without caching.)

AND, second question: The cashing itself is irritating, but as I have no quota on my ISP..... BUT why is nearly *everything* blocked during this "cashing downloads":

- Dolphin is completely unusable while downloading
- within bash a <TAB> completion "locks" the bash
etc.

Is this really unavoidable, could the caching not "nice"ly be done in the background ?

Regards,
Michael

Michael <michaelof>
Wed 22 Jun 2016 07:25:07 PM UTC, comment #2: 

ls does not trigger any file download. Files are fetched from the server when they are opened by an application. The problem are graphical file managers and file choosers that open any file for no good reason, e.g. some preview icon.

Please have a look at
http://savannah.nongnu.org/support/?109044
where most of the problem and possible workarounds are discussed.

Werner

- <_71007>
Tue 21 Jun 2016 09:35:18 PM UTC, comment #1: 

I've just seen that one 1GB file is currently downloaded by the daemon for the second time. Trigger might be just a "ls" on the davfs2 share folder.

The file itself is unchanged since first cache download.

Michael <michaelof>
Tue 21 Jun 2016 09:27:53 PM UTC, original submission:  

Hallo Werner,

guess we should stay in English for anyone else :-)

I need to use my German Telekom "MagentaCloud" Share more intensive, and because of that I started to use the webdav connectivity. My System is OpenSuse Leap 42.1. Tried at first the builtin webdav integration in KDE/Plasma's Dolphin, does not work. Takes any file on upload, states much higher upload rates as possible for my VDSL connection, and, 100% reproducible, terminates at ~ 98% with a message "Server has terminated the connection", or similar.

That's why I tried to go further with davfs2. My version is 1.5.4-5.1, available only as an "unstable" pkg for OpenSuse, whyever.

When using davfs, the mount itself works fine. But directly after the mount the system becomes nearly completely unresponsive in all file system related activities. E.g. open Dolphin windows on the mounted webdav share takes ~ 30 minutes to show the content. Bash's TAB path completion on the mounted share the same. Even a "kill -9" does not close a Dolphin window, showing on the share. Checked that CPU usage was marginal, Enough free RAM = no swapping etc.

After the first uploads of a couple of split 7z-files, each 1GB in size, I was affected by a "file system full" because everything uploaded was put into /var/cache also. I didn't know this before and was highly amused that uploads from and external USB HDD to the MagentaCloud are cached on my internal SDD :-S

To avoid this for the future, I've changed the cache directory in /etc/davfs2/davfs2.conf to a folder on the USB HDD. Which is fine for me, as all files to or from the share are on this USB HDD.

I've found out that after the mount (did it a root, no need for user mount, so in fact default daemon user) the daemon starts to download * EACH * file from the webdav share to the davfs2 cache directory. GBytes in my case, does not make fun even on a VDSL50 connection. It seems, that this happens only once, and the files are dropped later.

I've got why you're intensively caching, but why downloading all this stuff, just for an index, or is there another reason?

And a general question: Is this drop in response time for Dolphin etc. a bug, or could be changed somehow? In my case each new access to the share, each upload again e.g., puts everything "on hold" again :-(

Michael <michaelof>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by michaelof (Submitted the item)
  • -email is unavailable- added by michaelof
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-26 _71007 Open/ClosedOpen Closed
    2016-06-22 _71007 StatusNone Duplicate
        Assigned toNone _71007
    2016-06-21 michaelof Carbon-Copy- Added michaelof

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code