maindavfs2 - Support: sr #107978, DropBox - like caching?

 
 

sr #107978: DropBox - like caching?

Submitter:  None
Submitted:  Sat 03 Mar 2012 07:42:18 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  1 - Wish Status:  Wont Do
Privacy:  Public Assigned to:  _71007
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 26 Dec 2019 11:14:22 AM UTC, comment #3: 

When I noticed that this is harder than expected I could not make up my mind about what to do.

As you surely have noticed: I am not able to do this. Sorry for not answering in time.

Werner

- <_71007>
Sun 04 Mar 2012 08:09:35 PM UTC, comment #2: 

Yes, "allow_offline" as you sketch it would be a great progress towards use in roaming or other circumstances without connectivity. 

Maybe the size of downloaded tree could be managed through the cache size. Some flag like "aggressive_caching" could additionally cache the files with the most recent timestamps, as they are most likely to be looked at, even if I have not opened them yet, up to a limit of my cache size.

Leaving conflict resolution in the user's responsibility with lost&found would be sufficient for the moment, I think.

Thank you for the quick reply, hopefully "allow_offline" makes it into the TOOD list ;-)

Cheers,
Roland

Anonymous
Sun 04 Mar 2012 09:54:35 AM UTC, comment #1: 

At the moment davfs2 does not allow offline operation because the file system interface has no means to inform the user about this. So a user might work offline for a long time without noticing that some network problem prevents synchronizing with the server.

But I agree that it might be a configuration option putting the responsibility on the user. What I could imagine is:

  • adding an option like 'allow_offline'
  • with this option davfs2 would serve all file system actions from the cache when the connection to the server fails
  • when online again davfs2 will upload changed and new files. This may slow down the file system interface because davfs2 is still single threaded.


What I would not like to do is to download the whole tree into the cache. This could cause a lot of useless traffic and also exhaust local storage space. davfs2 holds all files in the cache that have been opened once - as long as the maximimum cache size allows for this.

Also conflict resolution by creating new versions does not quite fit in my current picture of davfs2. At the moment davfs2 resolves conflicts by moving locally changed files that conflict with files that have been changed on the server by moving the local version into lost+found leaving it to the user to manually resolve the conflicts. (Creating a new version would not save the user from this task anyway.)

Would this meet your demands?

Cheers
Werner

P.S.: Given my free time and my list of TODOs don't expect any implementation soon. But at least this could make it into the list of TODOs.

- <_71007>
Sat 03 Mar 2012 07:42:18 PM UTC, original submission:  

When studying the caching options I was hoping to be able to behave davfs like a dropbox client. But it seems both for reading and writing a file I need access to a server. The caching options help to overcome unreliable connections, but to be able to read or write successfully the connectivity must be there.

Could we have davfs options, which
(1) is caching the whole tree and allows reading files also without server connectivity
(2) allow queuing and writes files, when I am online again.

Conflict resolution when writing may be simply solved by adding a new version, if the time stamps would indicate it.

Anonymous

 

(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 None (Submitted the item)
  •  

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-26 _71007 StatusIn Progress Wont Do
        Open/ClosedOpen Closed
    2012-03-04 _71007 Severity2 - Minor 1 - Wish
        StatusNone In Progress
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code