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