[owncloud-devel] Syncing with the new Shared model

Vincent Petry pvince81 at owncloud.com
Fri Jun 20 15:56:08 GMT 2014


Hi,

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.

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...

So yeah, probably not a good idea :-D

Cheers,

Vincent

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
> 



More information about the Devel mailing list