files don't update since a while

[h-2]

Steps to reproduce

1. change something in the filesystem without owncloud
2. look at the folder through owncloud
3. wait for cron-job to complete successfully or configure ajax refresh

Expected behaviour

Changes are not visible

Actual behaviour

Change should be visible

Server configuration

Operating system: FreeBSD 10.1-RELEASE-p10

Web server: lighttpd-1.4.39_1

Database: postgresql93-server-9.3.12

PHP version: php56-5.6.23

Nextcloud version: nextcloud-9.0.51

Updated from an older Nextcloud/ownCloud or fresh install: update from oc9 which was updated from oc8 (I think that's where things broke, between oc8 and oc9)

Where did you install Nextcloud from: official FreeBSD packages

Signing status (Nextcloud 9.0 and above):

Signing status

No errors have been found.

List of activated apps:

App list

Enabled:

• activity: 2.2.1
• admin_audit: 1.0.0
• calendar: 1.2.2
• comments: 0.2
• contacts: 1.3.1.0
• dav: 0.1.6
• federatedfilesharing: 0.1.0
• federation: 0.0.4
• files: 1.4.4
• files_external: 0.5.2
• files_pdfviewer: 0.8.1
• files_sharing: 0.9.1
• files_texteditor: 2.1
• files_videoplayer: 0.9.8
• firstrunwizard: 1.1
• notifications: 0.2.3
• provisioning_api: 0.4.1
• systemtags: 0.2
• tasks: 0.9.1
• templateeditor: 0.1
• updatenotification: 0.1.0
  Disabled:
• encryption
• external
• files_trashbin
• files_versions
• gallery
• user_external
• user_ldap

The content of config/config.php:

Config report

'oc337af89298', 'passwordsalt' => 'FOO', 'secret' => 'BAR', 'trusted_domains' => array ( 0 => '192.168.3.202', 1 => 'BAX, ), 'datadirectory' => '/usr/local/www/nextcloud/data', 'overwrite.cli.url' => 'http://192.168.3.202', 'dbtype' => 'pgsql', 'version' => '9.0.51.0', 'installed' => true, 'forcessl' => true, 'maintenance' => false, 'dbname' => 'owncloud', 'dbhost' => '192.168.3.203', 'dbuser' => 'oc_user', 'dbpassword' => '', 'loglevel' => 1, 'theme' => '', 'appcodechecker' => false, 'mail_smtpmode' => 'sendmail', 'mail_from_address' => 'owncloud', 'mail_domain' => 'BAT', 'htaccess.RewriteBase' => '/', );

**Are you using external storage, if yes which one:** no **Are you using encryption:** no **Are you using an external user-backend, if yes which one:** no ### Logs #### Web server error log

Web server error log

nothing

#### Nextcloud log (data/nextcloud.log)

Nextcloud log

only unrelated stuff

### Further remarks If I run `./occ file:scan --all` everything works fine (although it takes 10min to scan. I am pretty sure it is something that is broken in cron.php, possible related to locking on FreeBSD? If I run `/usr/local/bin/php -f /usr/local/www/nextcloud/cron.php` manually from the command line the command returns almost immediately with no output and return value 0. However the indicator in the owncloud is updated to show that a cron jub ran successfully.

[rullzer]

This is the expected behaviour. The database is our source of all info. So if you change something on disk we won't pick it up until a scan is triggered.

If we wouldn't do this performance would be painfully slow.

[h-2]

Thank you for your reply!

This is the expected behaviour. The database is our source of all info. So if you change something on disk we won't pick it up until a scan is triggered.

But isn't cron.php supposed to be this "scan"? What I am trying to say is that changes are never picked up automatically on my system. Only running ./occ file:scan --all manually will.

[rullzer]

Ah no. cron.php is supposed to handle our cronjobs. Like expiring shares, deleting old entries in the trashbin etc.

The point here is that besides checking all the files in the data directory there is no way to find out if files have changed. (that is exactly what ./occ file:scan --al does). And as you can see that takes a lot of time. Now imagine a big installation with 1000ths of users and you see this will quickly break everything.

We assume all actions to the files go trough out API. So we only have to update what changed. If you want to touch files directly you are probabaly better of using external storages. There is work in progress to get more notification for at least Samba/CIFS shares

[h-2]

Ah, ok. That explains the difference. I used to have external storage for the directories in question, but I changed to regular storage and nullfs mounts, because there where security issues with the local external storage.
I will just create a nightly cron job that rescans the affected directories.