[owncloud-devel] Should we sync hard links?
jospoortvliet at gmail.com
Wed Jul 1 06:57:12 GMT 2015
On Tuesday 30 June 2015 16:29:28 Olivier Goffart wrote:
> Historically we have not sync'ed hard links. The sync client just ignores
> However, there are some good use case to sync them anyway:
> In that bug, NTFS filesystem mounter from linux have hardlinks and
> therefore you cannot sync a folder on NTFS on linux.
> So I was wondering if we should just change the code an just synchronize
> hard links.
> I'm only talking about hard links, NOT symbolic links.
> Hard links are two files with the same inode and the same contens on the
> same file system.
> I don't really know what is the use cases for hard links. It is often cited
> as a way to save space if two files share the same contents.
> Anyway, what would be the consequencies of not ignoring hard links?
> Well, they would simply be uploaded to the server. If there are two linked
> files within the sync directory, the two would be synced independently.
> (This waste a bit of bandwidth but i think it's ok)
> When a file is updated on the server, we would just download it and break
> the link. (because we download and move, the link will be removed)
> Even in case of rename the sync would not be dusrupted.
> So the question is: Is there any use case in which not ignoring hard links
> would break things?
I can't think of any but I don't do complicated stuff. What I do think is
that one makes a hard link explicitly because those are not to be ignored -
otherwise, use a soft link. I am used to software ignoring soft links for
security and performance reasons, but hard links - I didn't even know you
COULD ignore them and I wouldn't expect ownCloud to do so.
The update behavior (esp where it breaks hard links on changes) is a bit
unfortunate but not unexpected, I doubt it'll break anything.
Everything I do and say is based on my view of the world today. I am not
responsible for changes in the world, nor my view on it. Everything I say is
meant in a positive and friendly way, unless explicitly stated otherwise.
find me on blog.jospoortvliet.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part.
More information about the Devel