I have a dropbox external files link into my OwnCloud instance.
I ran a Files:scan and it seemed to be taking a very long time. Apart from the dropbox link, there is not a tremendous amount of data on the server, so a scan should be quick.
data/admin/files$ find . -type f | wc -l
74
However:
+---------+-------+--------------+------------------+
| Folders | Files | Elapsed time | Items per second |
+---------+-------+--------------+------------------+
| 2190 | 16982 | 02:09:16 | 2 |
+---------+-------+--------------+------------------+
Is it possible to do a files:scan for the user who has the dropbox link and instruct it to exclude dropbox?
I tried --path="/user/files", thinking that because there is no actual evidence of the dropbox link there that it might be limited to only the content of that folder, but it still scanned through to dropbox:
sudo -u www-data php occ files:scan --path="/admin/files"
Scanning files for 1 users
Starting scan for user 1 out of 1 (admin)
^CInterrupted by user
+---------+-------+--------------+------------------+
| Folders | Files | Elapsed time | Items per second |
+---------+-------+--------------+------------------+
| 393 | 2716 | 00:22:43 | 2 |
+---------+-------+--------------+------------------+
No, it’s not a mount. I set it up using the External Storage: Dropbox app, which creates a link into OwnCloud using the Dropbox API.
I am not sure how this is achieved in respect of file storage on the local main file repository. I am pretty sure the files in dropbox are not synced to the owncloud instance and shared from there. My assumption is that the file structure visible on OwnCloud is merely a window via the API, to the files on the dropbox instance.
Hence, you’ll see in my snips that I only have 74 files in my admin/files folder and yet the scan checked 16,982 files (at 2 per second!)
It seems that files:scan reads through the API link to dropbox to check the OwnCloud index. As this is happening via an internet connection, it isn’t quick.
The scan did actually achieve something, as some recent changes in Dropbox which were not reflecting in OwnCloud did then reflect. Which is another problem, because rescanning as you can see took hours, and if changes I make in Dropbox aren’t reflecting in OwnCloud then my intention in setting up the link is thwarted. Period 2 hour rescans are not the solution.
(And in the meantime, I tried creating the Dropbox link again from scratch - after a day it lost contact and I had to do it again. Any shares through OwnCloud of files in Dropbox then have to be re-created. So that’s also a game-stopper).
Thanks for the links. Very helpful. My final paragraph in my previous post is now explained - DB stopped allowing long lived tokens. So that seems to mean a link to DB will only last a day. Now to see if there’s a way around that as it means that the integration is effectively useless.
Actually I think the solution is to give up on the App and rather install db-headless on the host and then bring it into OC via a local external folder. So that is what I shall do. Will also allow files:scan to work faster. Does mean my db files are now taking up space on my host, but I have space so that’s okay.