[owncloud-devel] Syncing with the new Shared model

Klaas Freitag freitag at owncloud.com
Tue Jun 24 08:43:27 GMT 2014

On 20.06.2014 17:56, Vincent Petry wrote:

> Little shot in the dark: would it be possible to use extended
> attributes to store the local etag of the file/folder ?
> If the user moves it then the etag will probably move with the
> file/folder.
Yes, I tested that on linux: If you move a file, the attr is preserved, 
if the file is copied, the attr is _not_ preserved. That is exactly the 
behavior we need.

> On Linux extended attributes are usually enabled by default
> (user_xattr) on home mounts.
> On Mac I think I heard about such attributes existing as well and are
> possibly even used by the Mac Office suite (notes, etc).
> On Windows, I'm not sure whether NTFS supports it.
> Also some people might still store their files on FAT partitions...
Yes, but FAT not a good choice for synced data anyway and NTFS is 
default since Win XP.

> So yeah, probably not a good idea :-D
I disagree. We probably want to investigate more, but I think it is a 
promising idea: We store the fileid as extended attribute. And if the 
sync algorithm detects that a file is not longer there, it will check 
all new files if they have the missed fileid (which we know from the 
local sync journal db) in their extended file attribute. If yes, the 
file was moved.

have fun,


> On 06/20/2014 04:48 PM, Bjoern Schiessle wrote:
>> Hi Olivier,
>> On Thu, 19 Jun 2014 12:46:58 +0200 Olivier Goffart wrote:
>>> ownCloud 7 is about to introduce a new model for shared folder.
>>> Please someone correct me if i am wrong:
>>> - In ownCloud 6, all shared folder were sub-folders of the
>>> "Shared/" directory - In ownCloud 7, shared folders first appears
>>> as 'normal' folder in the root directory, but the user can then
>>> move them anywhere.
>> that's correct.
>>> So the question is:  Should we really try to support moving the
>>> shared directory from the client?
>> I think we should try to support it. Organizing your shares freely
>> was one of the main goal for the changes. It would be really bad if
>> it would only work for the web interface.
>>> Should we try to get more elaborate algorithm to detect moves in
>>> order to get this use case properly (tree comparison)?
>> Probably we have to think about it.
>> If I understood you correctly this is only a issue if changes
>> happen on the client side while the sync client doesn't run. Maybe
>> we could split-up the sync client in two components. One component
>> could by a small daemon who gets started with the system and
>> monitors the changes to the file system. If the user starts the
>> ownCloud sync client we could ask the daemon what happened. Sure,
>> the admin could still stop the daemon. But that's something
>> different from closing a application in the system tray.
>> That's just a random idea I had in mind while reading your mail.
>> The main idea is to always track file system changes, even if the
>> user decides to stop the sync client for some reasons (e.g. because
>> he is in a local network and don't want that the sync client tries
>> to re-connect again and again). I don't know much about the
>> internals of the sync client. Maybe it is a bad idea.
>>> Should we ignore this problem as a corner case? (IMHO not,
>>> because its implication are bad enough).
>> I don't think we should ignore it. Sharing documents by accident
>> can be really painful. This should be avoided at all costs.
>> cheers, Björn
>> _______________________________________________ Devel mailing list
>> Devel at owncloud.org
>> http://mailman.owncloud.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at owncloud.org
> http://mailman.owncloud.org/mailman/listinfo/devel

More information about the Devel mailing list