bugfix for syncing the Shared-folder

[schiessle]

This fixes the problem we had while syncing the Shared folder (issue #260).

• The main problem was that the etags where stored for each virtual "Shared-folder-path" but not for the real physical path. To detect changes from every user with access to the file I now store only the real path in the properties table.
• Since I need to get the origin file source of a shared folder/file I created a new class OC_Files_Sharing_Util which provides public access to the necessary code originally implemented in OC_Filestorage_Shared. For now I just copied the necessary functions over to the new class to avoid unwanted side effects. @MTGap please have a look at both classes if it is safe to always point to the function in apps/files_sharing/lib/util.php.
• Since it is quite hard and expensive to find all users which have access to a particular file I decided to always modify the etag for the Shared folder. This means that for every check the sync client will look in the root sync dir and the root of the shared folder for changes.

@dragotin and @danimo please also have a look at it and test it with the desktop client.

[AndreFabris]

Let me know how to test this and does it also affect the duplications created

[schiessle]

@AndreFabris For testing you need to check out the sharing_folder_sync branch from owncloud/core. Regarding the duplicates: I'm not sure, I never experienced duplicates during my tests.

[AndreFabris]

Well the fix ste80pa suggested in the other thread worked for me.

I should said conflicts, not duplicates. Keep getting conflicts on the Windows client, but not on the server side or when browsing.

It is strange that out of 100MB of files, 15 folders each with numerous subfolders only two seem to be affected. One with 2 files and other one with 94. Every file is downloaded twice, exact same copy with additional word conflict + date in the file name

Mac client seems to work at the moment, Only Windows 1.1.1 has this error (tested on 2 PCs)

[ste80pa]

AndreFabris : to avoid duplicates on client side :

1] stop owncloud client
2] delete cysnc_stae db. My db is located at C:\Documents and Settings\ste80pa\Local Settings\Application Data\ownCloud\csync_statedb_4831275572097373574.db
3] go on server side an delete all conflicting and duplicate files and clear oc_properties table as i described in the other post
4] on local folder, controlled by owncloud client, delete all files and folders
5] restart ownlcoud client

[MTGap]

This doesn't seem like a solution to me, if anything it is a temporary fix. What about external storage mounted for multiple users? It seems the storage of etags needs to be refactored to decouple from the user. @icewind1991, can we store the etags in the file cache?

[ste80pa]

Thi s is only a temporary workaround :(

[schiessle]

External storages have to be checked anyway for every sync since you never know whether something was changed or not. I don't see a connection to the problem we discuss here.

Sure we could think abut a complete different etags table but this needs time and needs to be well thought out. First we need to get stable45 stable and as bug free as possible.

[scroogie]

Could you perhaps have a look at pull request #271 (#271)? I guess you're comfortable with the API/table etc. now and could maybe give a suggestion.

[schiessle]

I made a new pull request for the stable45 branch. For master we decided to wait until the new file cache is in place.

#335

[karlitschek]

@icewind1991 Do you have an ETA for the improved filesystem cache? I don´t like to have a broken master for a long time.

[icewind1991]

I'm hoping to get it ready for testing in a week

[karlitschek]

Awesome :-)

[DeepDiver1975]

@icewind1991 which branch holds the new implementation?
I can setup a Jenkins job if you wish.
Take care

[icewind1991]

On Friday 09 November 2012 05:03:16 Thomas Müller wrote:

@icewind1991 which branch holds the new implementation?
I can setup a Jenkins job if you wish.
Take care

---

Reply to this email directly or view it on GitHub:
#323 (comment)

It's in the filesystem branch but it doesn't need a jenkins job yet

• Robin Appelman