Bug report for OS X client

OS X client Sync to Linux server has issues - appears to be related to the OS X users home directory being a symlink.

Steps to reproduce
1. Add a file to ~/ownCloud directory on client
2. Wait - (10 mins+) no sync 0ccurs
3. Click Pause/UnPause sync and it will start to sync

Expected behaviour
Adding a file should sync without needing to Pause/UnPause

Actual behaviour
No sync - we need to Pause/Unpause the client (perhaps 10 mins later) for the sync to happen to the server

Client configuration
Client version: 2.2.3 (also 2.1, 2.2)
Client operating system: OSX 10.11.6

Server configuration
Operating system: Centos 7.2
Web server: Apache 2.4.6
Database: mariadb 1.5.5
PHP version: php5.5
ownCloud version (see ownCloud admin page): 9.1
Updated from an older ownCloud or fresh install: Updated from 9.0
ownCloud log (data/owncloud.log):

Special configurations (external storage, external authentication, reverse proxy, server-side-encryption): On the client the home directory is in one place but symlinked to somewhere else in order to match our other Linux machines. Perhaps this is messing owncloud client up?

The client log indicates that when the file is added the first time it is ignored (although no ignore options have been set), the ignore files is given as '*' i.e. everything. This however can not be the case because pause/unpause then starts the sync.

Initial problem
I removed the ~/ownCloud directory and then mkdir ~/ownCloud (this is set in the symlinked home directory to be /home/disk3/jon/ownCloud), I then restarted the owncloud client and everything sync'd fine from the server. using this new ownCloud directory I then added a file (cp ... ~/owncloud) and it was not sync'ed to the server.

Debugging attempts
On adding the file:
08-10 13:11:33:366 0x7fe941f13500 OCC::FolderMan::slotFolderSyncFinished: <===================================== sync finished for "https://xxx.xxx.org/owncloud/remote.php/webdav/"
08-10 13:11:35:205 0x7fe941f13500 -[DelegateObject updaterDidNotFindUpdate:]: -[DelegateObject updaterDidNotFindUpdate:]
08-10 13:11:39:794 0x7fe941f13500 OCC::callback: FolderWatcherPrivate::callback by OS X
08-10 13:11:39:796 0x7fe941f13500 OCC::FolderWatcher::pathIsIgnored: * Ignoring file "/Volumes/userdir/disk3/jon/ownCloud/sofee.jpg"
08-10 13:11:39:817 0x7fe941f13500 OCC::callback: FolderWatcherPrivate::callback by OS X
08-10 13:11:39:828 0x7fe941f13500 OCC::callback: FolderWatcherPrivate::callback by OS X
08-10 13:12:28:680 0x7fe941f13500 OCC::Folder::slotRunEtagJob: * Trying to check "https://xxx.xxx.org/owncloud/remote.php/webdav/" for changes via ETag check. (time since last sync: 55 s)
08-10 13:12:28:681 0x7fe941f13500 OCC::FolderMan::slotRunOneEtagJob: Scheduling "https://xxx.xxx.org/owncloud/remote.php/webdav/" to check remote ETag
08-10 13:12:28:682 0x7fe941f13500 OCC::AbstractNetworkJob::start: !!! OCC::RequestEtagJob created for "https://xxx.xxx.org/owncloud" + "/" "OCC::Folder"
08-10 13:12:38:610 0x7fe941f13500 OCC::Folder::saveToSettings: Saved folder "ownCloud" to settings, status 0
08-10 13:12:38:612 0x7fe941f13500 OCC::SocketApi::sendMessage: SocketApi: Sending message: "STATUS:OK:/home/disk3/jon/ownCloud"

it see the new file sofee.jpg but ignores it for some reason (the '*' I guess it's because it only looks for the symlinked /home/disk3/jon and ignores the fact that /Volumes/userdir/disk3/jon is the original copy).

After Pause/UnPause
I then pause OC client:
xxx.xxx.org/owncloud/remote.php/webdav/" : "Sync Paused"
08-10 13:12:38:630 0x7fe941f13500 OCC::SocketApi::sendMessage: SocketApi: Sending message: "UNREGISTER_PATH:/home/disk3/jon/ownCloud"

After unpausing, it sync's

08-10 13:16:35:214 0x7fe941f13500 OCC::SyncEngine::startSync: =====sync with existing DB
08-10 13:16:35:215 0x7fe941f13500 OCC::SyncEngine::startSync: =====Using Qt 5.4.0
08-10 13:16:35:215 0x7fe941f13500 OCC::SyncEngine::startSync: =====Using SSL library version OpenSSL 1.0.2h 3 May 2016
08-10 13:16:35:216 0x7fe941f13500 OCC::SyncEngine::startSync: void OCC::SyncEngine::startSync() ====NOT Using Selective Sync
08-10 13:16:35:216 0x7fe941f13500 OCC::SyncEngine::startSync: #### Discovery start #################################################### >>
08-10 13:16:35:217 0x7fe941f13500 OCC::SyncEngine::startSync: =====Server "" "rootEtagChangesNotOnlySubFolderEtags=1"
08-10 13:16:35:464 0x7fe941f13500 OCC::SocketApi::sendMessage: SocketApi: Sending message: "STATUS:SYNC:/home/disk3/jon/ownCloud/sofee.jpg"

08-10 13:16:35:540 0x7fe941f13500 OCC::AbstractNetworkJob::start: !!! OCC::PUTFileJob created for "https://xxx.xxx.org/owncloud" + "/sofee.jpg" ""
08-10 13:16:35:765 0x7fe941f13500 OCC::PropagateUploadFileQNAM::slotPutFinished: void OCC::PropagateUploadFileQNAM::slotPutFinished() QUrl( "https://xxx.xxx.org/owncloud/remote.php/webdav/sofee.jpg" ) FINISHED WITH STATUS 0 "" QVariant(int, 201) QVariant(QString, "Created")
08-10 13:16:35:766 0x7fe941f13500 OCC::PropagateUploadFileQNAM::slotPutFinished: == duration UPLOAD 985231 10 15 243
08-10 13:16:35:767 0x7fe941f13500 OCC::SyncJournalFileRecord::SyncJournalFileRecord:

08-10 13:16:35:837 0x7fe941f13500 OCC::ownCloudGui::slotSyncStateChange: Sync state changed for folder "https://xxx.xxx.org/owncloud/remote.php/webdav/" : "Success"

So here it recognised it as being in the symlinked homedirectory and syncs it.

Partly resolved
I removed the ownCloud directory, removed the config file and restart OC client, this time I set the ownCloud directory manually as /Volumes/userdir/disk3/jon/ownCloud, after all the files from the server were sync'd I then added the sofee.jpg file and it was synced immediately. Therefore the issue is something to do with there being two ways to access the client local owncloud directory and the OC client not recognising this.

While this may seem trivial to resolve by setting up ownCloud again we have lots of users and for them when they setup they really need to jsut be able to click the default for creating the local ownCloud dir which will be the symlinked one.


Bug report for OS X client

if you're sure this is a bug in the OS X client then please report it directly to the bugtracker:


Also closing as a duplicate of:

Please avoid creating doubled posts about the same issue. Thanks