On Tuesday 24 June 2014 10:43:27 Klaas Freitag wrote: > On 20.06.2014 17:56, Vincent Petry wrote: > 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. > > 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.
Note that desktop indexers like Baloo and applications like Amarok also track files around - might be worth seeing what they use for that... > have fun, > > Klaas > > > 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 > >> [email protected] > >> http://mailman.owncloud.org/mailman/listinfo/devel > > > > _______________________________________________ > > Devel mailing list > > [email protected] > > http://mailman.owncloud.org/mailman/listinfo/devel > > _______________________________________________ > Devel mailing list > [email protected] > http://mailman.owncloud.org/mailman/listinfo/devel
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devel mailing list [email protected] http://mailman.owncloud.org/mailman/listinfo/devel
