Federated shared subfolder not syncing. #20329

Closed
ronbailer opened this Issue Nov 5, 2015 · 28 comments

Projects

None yet

10 participants

@ronbailer

Steps to reproduce

  1. create user1 and user2 accounts.
  2. user1 syncs root folder in desktop sync client (using default client settings).
  3. user1 create a directory A and subdirectory B in A.
  4. user1 share a subdirectory B whith user2 using federated cloud sharing (user2@myowncloudurl) whith edit permissons.
  5. user2 access accross web interface and accept the new shared folder.
  6. user2 upload f1 file into B folder.

Expected behaviour

user1 sync client download f1 in B folder.

Actual behaviour

The f1 file (uploaded by user2) is not synced in user1 computer.
But if user1 move B subdir to root folder everythings work properly.

Server configuration

Operating system:
Debian 7
Web server:
Apache 2.2.22
Database:
Mysql 5.5
PHP version:
5.5.30 (Apache lib mod)
ownCloud version:
8.1.4
Updated from an older ownCloud or fresh install:
Upgraded across all versions since Owncloud 4.5

Client configuration

Operating system:
Windows 10
ownCloud client version:
2.0.2

@karlitschek karlitschek added the bug label Nov 5, 2015
@karlitschek
Member

@schiesbn any idea?

@PVince81
Collaborator
PVince81 commented Nov 6, 2015

Pretty sure I've seen this before. If someone finds the duplicate, please link it. Thanks.

@ronbailer

I tested with owncloud 8.2 and so happen. Someone has been able to reproduce?

@ronbailer

Same issue happens in OC 8.2.1 :-(

Any news about this?

@PVince81 PVince81 added this to the 9.0-current milestone Dec 14, 2015
@PVince81
Collaborator

@schiesbn can you have a look ?

@icewind1991 is that the update detection issue ?

@Helios07
Helios07 commented Feb 5, 2016

I just experienced a very similar problem that was reported by one of our users. Our scenario differs a little but I think it has the same origin as the one described here.

  • User1 either shares via federated sharing or with a link with user2 (I tried both with the same results)
  • User2 accepts the share respectively adds it to his ownCloud
  • User2 creates another folder in his local file system in the shared folder and a file in this folder (but I think the latter is not necessary to trigger the error)
  • The desktop client of user2 uploads the new folder (and the file within) and his other clients download those within 30 seconds
  • Now you would expect user1's desktop client to do the same, but it doesn't. User1 has to restart his client in order to get the files downloaded to his desktop

The error also occurs if user1 and user2 are located on the same server. (Update: We are running 8.1.4EE)

I checked the (F12) Logs of the client that should have downloaded the files, there were no entries.

@michaelstingl

@MorrisJobke Could you check the status?

00004741

@MorrisJobke
Member

I just tested the steps of the initial post and this works in current master:

bildschirmfoto 2016-02-10 um 14 02 12

Etags before the upload:

morrisjobke@gymir:~ » curl -i -X PROPFIND http://localhost/master/remote.php/webdav  -u abc:abc -s | egrep "href|etag"
  <d:href>/master/remote.php/webdav/</d:href>
    <d:getetag>&quot;56bb339670b25&quot;</d:getetag>
  <d:href>/master/remote.php/webdav/A/</d:href>
    <d:getetag>&quot;56bb3396709e1&quot;</d:getetag>
  <d:href>/master/remote.php/webdav/welcome.txt</d:href>
    <d:getetag>&quot;3387fbfb7175404a7ae56fa7a2096139&quot;</d:getetag>
morrisjobke@gymir:~ » curl -i -X PROPFIND http://localhost/master/remote.php/webdav/A  -u abc:abc -s | egrep "href|etag"
  <d:href>/master/remote.php/webdav/A/</d:href>
    <d:getetag>&quot;56bb3396709e1&quot;</d:getetag>
  <d:href>/master/remote.php/webdav/A/B/</d:href>
    <d:getetag>&quot;56bb339670064&quot;</d:getetag>

etags after the upload:

morrisjobke@gymir:~ » curl -i -X PROPFIND http://localhost/master/remote.php/webdav  -u abc:abc -s | egrep "href|etag"
  <d:href>/master/remote.php/webdav/</d:href>
    <d:getetag>&quot;56bb343f00d4b&quot;</d:getetag>
  <d:href>/master/remote.php/webdav/A/</d:href>
    <d:getetag>&quot;56bb343f00bb8&quot;</d:getetag>
  <d:href>/master/remote.php/webdav/welcome.txt</d:href>
    <d:getetag>&quot;3387fbfb7175404a7ae56fa7a2096139&quot;</d:getetag>
morrisjobke@gymir:~ » curl -i -X PROPFIND http://localhost/master/remote.php/webdav/A  -u abc:abc -s | egrep "href|etag"
  <d:href>/master/remote.php/webdav/A/</d:href>
    <d:getetag>&quot;56bb343f00bb8&quot;</d:getetag>
  <d:href>/master/remote.php/webdav/A/B/</d:href>
    <d:getetag>&quot;56bb343f00a8f&quot;</d:getetag>
@MorrisJobke
Member

I could reproduce this in stable8.2:

bildschirmfoto 2016-02-10 um 14 09 41

The etag of the folder B has changed, but for folder A this has not changed:

Before:

morrisjobke@gymir:~ » curl -X PROPFIND http://localhost/master/remote.php/webdav  -u abc:abc -s | xmllint --format "-"| egrep "href|etag"
    <d:href>/master/remote.php/webdav/</d:href>
        <d:getetag>"56bb355d0dea8"</d:getetag>
    <d:href>/master/remote.php/webdav/A/</d:href>
        <d:getetag>"56bb355d0e06d"</d:getetag>
    <d:href>/master/remote.php/webdav/welcome.txt</d:href>
        <d:getetag>"b6ac479a5830082e975888e5f9d9d3ad"</d:getetag>
morrisjobke@gymir:~ » curl -X PROPFIND http://localhost/master/remote.php/webdav/A  -u abc:abc -s | xmllint --format "-"| egrep "href|etag"
    <d:href>/master/remote.php/webdav/A/</d:href>
        <d:getetag>"56bb355d0e06d"</d:getetag>
    <d:href>/master/remote.php/webdav/A/B/</d:href>
        <d:getetag>"56bb355d0d53b"</d:getetag>

After the upload:

morrisjobke@gymir:~ » curl -X PROPFIND http://localhost/master/remote.php/webdav  -u abc:abc -s | xmllint --format "-"| egrep "href|etag"
    <d:href>/master/remote.php/webdav/</d:href>
        <d:getetag>"56bb355d0dea8"</d:getetag>
    <d:href>/master/remote.php/webdav/A/</d:href>
        <d:getetag>"56bb355d0e06d"</d:getetag>
    <d:href>/master/remote.php/webdav/welcome.txt</d:href>
        <d:getetag>"b6ac479a5830082e975888e5f9d9d3ad"</d:getetag>
morrisjobke@gymir:~ » curl -X PROPFIND http://localhost/master/remote.php/webdav/A  -u abc:abc -s | xmllint --format "-"| egrep "href|etag"
    <d:href>/master/remote.php/webdav/A/</d:href>
        <d:getetag>"56bb355d0e06d"</d:getetag>
    <d:href>/master/remote.php/webdav/A/B/</d:href>
        <d:getetag>"56bb36585781d"</d:getetag>

@icewind1991 I guess this is because of the recent changes to the etag propagation that now works on a per-storage level. Could you link to that issue/PR? I only found the latest cleanups: #20875

@cmonteroluque
Contributor

@schiesbn @icewind1991 ping

@PVince81
Collaborator

@MorrisJobke Per-storage level etag propagation is a 9.0 feature, not 8.2.2.

@MorrisJobke
Member

@MorrisJobke Per-storage level etag propagation is a 9.0 feature, not 8.2.2.

@Helios07 As said - sadly we can't backport this to stable8.2 because it involves too many changes.

@DeepDiver1975 DeepDiver1975 changed the title from Federated shared subfolder not syncing. to Federated shared subfolder not syncing. Feb 12, 2016
@MorrisJobke MorrisJobke reopened this Feb 15, 2016
@MorrisJobke
Member

This is quite critical for @Helios07 - @PVince81 @icewind1991 is there any chance to implement a hot fix for the stable8.2 branch?

@cmonteroluque
Contributor

@MorrisJobke will be looking into something quick

@cmonteroluque
Contributor

@schiesbn any chance you can have an urgent look at this please?

@schiessle
Member

I can re-produce it. What I don't get at the moment... but I will try to find out:
We are talking about etag propagation at the owner side, not at the recipient side. So there are no different sorages, etc. Just a folder structure A/B. If I upload a file to B with webdav (cadaver) the etag gets propagated correctly. If I upload a file from a second ownCloud which mounted B as a federated share we only update the etag of B but not of A. Even if technically it is in both cases a webdav upload to A/B. What's the difference here?

@PVince81
Collaborator

Weird... There should be no difference if it's a webdav upload, it should always propagate the etag up to the root (well, up to "/files" at least)

@schiessle
Member

Yes, that's really weird. For some reasons when we propagate the changes from the federated share upload the path is //filename while on the webdav upload the path is /A/B/filename. That explains while the propagation fails for a federated share upload. In this case it only propagates the changes up to '/' which seems to be 'B'. But I couldn't find out why the paths are different. It looks like we interpret the target folder ('B') as the storage root, but why?

@schiessle
Member

@icewind1991 any idea where this strange behavior comes from?

@icewind1991
Member

iirc the external share dav works on a View that's rooted at the share root (/A/B) and not the user's home folder and propagation (in 8.2) goes up to the view's root.

it's fixed in 9.0 because the view root no longer has any impact on propagation

@schiessle
Member

iirc the external share dav works on a View that's rooted at the share root (/A/B)

What's the reasons for that? Why does the external share dav use a different root than a "normal" dav? Could this be a quick fix for 8.1/8.2 to change to root to the users home?

@icewind1991
Member

atm the dav servers works on top of a view, changing the root of the view would change the root of the dav server

@icewind1991
Member

A possible qf might be to change propagation to always run on the proper user view

@schiessle
Member

A possible qf might be to change propagation to always run on the proper user view

I tried now several approaches but couldn't find a solution. At the moment I don't see how this could work without large changes. But you know the code much better than me. Do you want to give it a try and propose a PR? This would be really helpful! Thanks!

@icewind1991
Member

Will have a go

@icewind1991
Member

#22676 should do it

@schiessle
Member

@icewind1991 great! Thanks a lot... I will try it.

@MorrisJobke
Member

I tested it and it works :) Thanks @icewind1991

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment