On 07/12/2012 04:17 PM, Michael Gapczynski wrote:
Hi Björn,
I thought I fixed all of these issues by updating the mtime of the shared
folder to trigger a scan, but I suspected issues might still be around.
However, I'm working on a refactored sharing in the share_api branch which
avoids using the file cache for shared files and prevents any of these
problems. Here's why I decided to keep the shared files out of the file cache:
- File cache needs to be updated manually because the file hooks don't work
across users, which is what you brought up
- mtime and size don't get updated, so this also has to be done manually
- Sharing a large folder can take a long time to scan again, causing a UI
delay
- Duplicate rows for files and performance costs for what can be achieved with
just the share table
The disadvantage of this, is that I had modify OC_Files to also return shared
files. This isn't something that I wanted to do because it means sharing isn't
independent of the core. I may change this in the future if I come up with a
better solution.
The new version of file sharing should be completed for the next release of
ownCloud.
Very great ideas and a shiny next stage of the refactored Sharing to
come! Nevertheless, we should not forget about the now ;) So isn't it
solveable for oC 4x? It's gonne be used for quite some time on a
personal as well as professional level, those issues generate quite some
annoyances.
Cheers
Arthur
Michael
On Thursday, July 12, 2012 02:05:14 PM Bjoern Schiessle wrote:
Hi all,
I discovered a fscache problem in connection with file sharing which I
want to share wit you and get your feedback.
The first time I share a file with a user, the operation works as
expected. I think that's the case because at the first time the
Shared directory gets created it triggers the right operation to update
the fscache.
But after that no further operation updates the fscache. Neither when I
unshare the file nor if I share additional files. That's the case
because for a virtual directory like "Shared"
OC_FilesystemView::basicOperation() never proceeds to the point where
it emits the post-hooks which would trigger the fscache update.
I think it is right to not execute the generic post hooks for the Shared
folder since the actual files aren't located there. So a lot of other
operations connected to the post hook would fail.
But this leads us to the question where to update the fscache if a
new file gets shared or a if a file gets unshared. I see two options:
1. Create special post hooks for the shared operations. This would
also allow other apps to subscribe to the same events which might be
useful in the future.
2. Instead of using hooks we could simply add/remove the new files
from the fscache directly in apps/files_sharing/lib_share.php where
also the oc_sharing table gets updated. The disadvantage here is that
fscache operations would happen in two different places.
What's your thoughts?
cheers,
Björn
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
_______________________________________________
Owncloud mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/owncloud
