Nextcloud Dev: 20170528: Some folders do not appear in the list.

[OlivierS1]

Actual behaviour

-Tell us what happens

It would seem that some folders are not listed in the list. I can't seem to find any trace of a particular one.
In the log, I have the following details:
`
2017/05/28 18:54:56
Brand : lge

2017/05/28 18:54:56
Product : g3_bell_ca

2017/05/28 18:54:56
Device : g3

2017/05/28 18:54:56
Version-Codename : REL

2017/05/28 18:54:56
Version-Release : 6.0

2017/05/28 18:54:56
Debug : start logging

2017/05/28 18:54:56
SyncedFolderObserverService : Start service SyncedFolderObserverService

2017/05/28 18:54:56
FileObserverService : onCreate

2017/05/28 18:54:56
FileObserverService : Starting command null

2017/05/28 18:54:56
FileObserverService : Loading all kept-in-sync files from database to start watching them

2017/05/28 18:54:56
ThumbnailsCacheManager : create dir: /storage/emulated/0/Android/data/com.nextcloud.android.beta/cache/thumbnailCache

2017/05/28 18:54:57
FolderObserver : Started watching parent folder /storage/B4BA-91D0/Android/media/com.nextcloud.android.beta/nextcloud/XXXXX@XXXXXXXXXX%2Fowncloud/Recettes/
`
The folder named "Recettes" is the one missing from the list.

Folder

Expected behaviour

-Tell us what should happen
All folder present under my account should be visible within the mobile app list.

Steps to reproduce

Environment data

Android version:
6.0

Device model:
LG 3 : LG-D852

Stock or customized system:
Stock

Nextcloud app version:
Dev 20170528
Nextcloud server version:
11.0.3

Logs

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

Insert your Nextcloud log here

NOTE: Be super sure to remove sensitive data like passwords, note that everybody can look here! You can use the Issue Template application to prefill some of the required information: https://apps.nextcloud.com/apps/issuetemplate

PR: #1165

[OlivierS1]

Doing side by side comparison between Nextcloud 1.4.3 and Nextcloud Dev 20170528, I found I am missing about 25 top level folders.
Content from 1.4.3 matches what I have on the web interface.
The missing folders seem to be the one that are shared, but not all of them it seems.

[AndyScherzinger]

@tobiasKaminsky @mario do you have the time to take a look at this?

[mario]

Sure l, but I would need reproduction steps :-/

…

On Tue, 30 May 2017 at 08:46, Andy Scherzinger ***@***.***> wrote: @tobiasKaminsky <https://github.com/tobiaskaminsky> @mario <https://github.com/mario> do you have the time to take a look at this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1047 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAWsnfvqK7-Gofu063YPEQwomKHMad4ks5r-7thgaJpZM4No1r9> .

[j-ed]

I think the issues #994, #468 are related to this issue. Wouldn't it be possible to add a kind of debug trace function to the app which can be enabled on a request so that you're able to narrow down the root cause of the problem?

Let me also point your attention to issue nextcloud/server#5153 which might also part of the whole problem.

[AndyScherzinger]

@j-ed @OlivierS1 are the folders that are missing any different from the ones you see? From what I understand for @OlivierS1 it seems to be happening for shared ones only but not all shared folders, so where do they differ? (any certain kind of sharing config? any certain kind of storage used for these folders?)

[j-ed]

The folders on my server are all WebDAV shares, which have been configured using the personal settings of my user. They're not shared nor is any "special" the configuration used.

Folder name.....: Bilder_Familie
External storage: WebDAV
Authentication..: Globale Anmeldeinformationen
Configuration...: <nas-server>:5006
                  /bilder
                  Use Secure https://

[OlivierS1]

@AndyScherzinger, difficult to isolate the root cause.
Only one folder from a SMB share, the rest are regular folders within my Nextcloud dataset.
I have been trying to change a few things on one particular folder named "Recettes" and I have noticed the following:

From the Web interface:

• Changing or removing shares didn't affect the outcome.

• When renaming the folder, it will appear with the new name.

• Renaming the folder back to "Recettes" and it will not be visible anymore.

• Copying the folder and contents to another folder, the new folder will be visible as well as the files within.

• Renaming "Recettes" to something else. The new folder name will be visible.

• Creating a new folder named "recettes", it is visible.

• Renaming "recettes" into "Recettes" and the new folder is no longer visible.

• Renaming "Recettes" to "recettes-mm". The new folder name will be visible.

• From the Dev app, I created the folder "Recettes" and it is visible.

• Deleted "Recettes" folder from the Web interface.

• Renamed "recettes-mm" to "Recettes", the folder is now visible in the Dev app.

I have created a new account and created a folder with the same name and it is visible.
I have saved the logs several times, and I couldn't find the folder I renamed. I am not sure how exactly the logging mechanism behaves and what is supposed to be recorded.

I thought there was something peculiar about the "FileObserver" and "FolderOberser" as it is listed for the folders that are missing, but only 3 folders out of the missing ones are showing in the log with this parameter/command.
Are my logs complete? I can't say.

I do not see any issues with Nextcloud 1.4.3.

I am wondering if some of the Dev features, if implemented are not causing this issue.
I used to have files and folders set as favorite and unset them, except for 3 of them, but the last 3 where not showing (they are part of the missing folders).

[OlivierS1]

Because I was able to restored "Recettes" from the mobile Dev app, I decided to uninstall the app and do a fresh install.
Now, it seems some of the previously missing folders are now visible. I don't know yet if all of them are visible yet.
I am wondering if any of the following could be the culprit:

• Thumbnail folder.
• Using more than one account on the Dev app.
• Nextcloud folder was moved to external storage and back to internal a few times.
• Successive updates of the Dev app in the past weeks leaving corrupted files or messing things up along the way.

[AndyScherzinger]

@mario @tobiasKaminsky any idea what could be or could have been causing this. Since 1.4.3 is fine and dev seems to have gotten "better" after re-install I don't have any idea. Only thing I did the last couple of weeks/month were UI implementations so I can't tell if we changes anything regarding fetching/storing of the remote file tree... :/

@OlivierS1 thanks a lot for the debug / testing efforts! <3 Quite detailed reports!

[OlivierS1]

@AndyScherzinger , The issue has reoccurred.
I am running Nextcloud Dev 20170609.
I don't know what caused it and if it is caused by any of the updates.

[tobiasKaminsky]

We need a reliable way to reproduce this, otherwise it is nearly impossible to help you.
Can you see any problems on the server, e.g. hdd/caching/problems?

[OlivierS1]

I think I have a pattern. I will have to provide both Nextcloud log and catlog later, but here are my findings:

To reproduce:
1: Create a folder.
2: share the folder
3: Go to "shared" page and wait for the content to be populated. Shared folder should show up here.
4: Go to "All files" page. The newly created, including the previously shared folders, are no longer visible.

[OlivierS1]

Did I mention this, I am not sure. It seems the folders I am having issue with are only the shared folders I own, not folders being shared with me by other users.

[OlivierS1]

On the server side, the error I have are as follow:

Error PHP array_flip(): Can only flip STRING and INTEGER values! at /usr/local/www/owncloud/lib/public/AppFramework/Http/EmptyContentSecurityPolicy.php#343
Debug core Scss is disabled for /usr/local/www/owncloud/core/css/share.scss, ignoring

[tobiasKaminsky]

@schiessle as this error might be related to sharing, can you help us with the error message?

[mario]

@tobiasKaminsky I would guess this is related to virtual files insite the app rather than the server.

[tobiasKaminsky]

Hmm, on point 4 he is using "all files" which is just a regular webdav call and file listing, nothin with virtual files.
But maybe we store the virtual files in a wrong way and thus they "disappear".

[mario]

Yes, that's what I'm aiming at.

[tobiasKaminsky]

@OlivierS1 thank you very much for your detailed steps to reproduce.
This made it very easy to fix this!

I will push it into next dev. Can you please give it a try? 👍

[mario]

@tobiasKaminsky where's the PR? :D

[tobiasKaminsky]

As always linked on the bottom of the first post and just above my comment
#1047 (comment) is link included by github as I referenced this issue from the pr.

--> #1165

[OlivierS1]

@tobiasKaminsky It seems to be working for now as I see some of my lost folders reappear in the "all files" page. However the folders I created the past few days to help establish a pattern for which some of them have been unshared, do not seem to reappear.
Sharing a new folder will appear in "Shared" page and unsharing will bring it back in "All files".
Updating the share property of the files used for testing yesterday back to shared will make it visible again. Unsharing it will make it disappear from "Shared" but will remain visible under "All files".

I suspect, there are some cache elements that just need to be refreshed by the app on the phone.
It seems to me the feature is working as intended. Performing a new install should resolve everything but I don't feel like doing it for now. Maybe later.

Thanks for the support.

[j-ed]

@tobiasKaminsky I've installed the latest appversion (20170706-dev) too, but unfortunately the original problem still persists.

[tobiasKaminsky]

@OlivierS1 glad to hear. Yes the shares are cached, re-installing will help (as it is a dev version I did no proper cleanup)

@j-ed is it also not working for new shares? Can you uninstall and re-install the app and test it again?

[j-ed]

@tobiasKaminsky First I've created a new WebDAV share. Second I've deinstalled the Nextcloud app an reinstalled the latest dev release. Third I've re-entered my Nextcloud credentials to access the server.
These are my findings:

1. The base directory tree was loaded/displayed instantly.
2. The content of local shares/directories was loaded/displayed instantly.
3. The content of a Google share was loaded/displayed instantly.
4. The content of the newly added WebDAV share was loaded/displayed instantly.
5. The content of the existing WebDAV shares wasn't loaded/displayed at all. Instead the loading wheel
   was displayed without coming to an end.

[tobiasKaminsky]

Are you sure this is the correct issue? This is about not showing shared folders at all.
I remember that we talked about webdav content in another issue? #468 maybe?

[j-ed]

You might be right depending on the point of view concerning this issue. Due to the fact that the relevant folders on my server are containing files and folders it might be a linked issue - but you're the specialist on it.

[OlivierS1]

@tobiasKaminsky I had to uninstall the app and perform a clean install.
Some files belonging to several shared folders which were changed in the past few days would not show up in the shared folder. The spinner would seem to run continuously.
After the clean install, by the way removing the account and leaving the app didn't solve the problem, so uninstalling the app itself seemed the only option, then at this point everything seem to be as expected.
As a Dev app, I wasn't too concerned about the issue. It is just as usual going the long way around.

[OlivierS1]

@j-ed Try deleting the User Nextcloud beta folder before doing a fresh reinstalling the Dev version. Make sure Dev app is unsinstalled.

[tobiasKaminsky]

@OlivierS1 once again thank you very much for your detailed and valuable feedback!
This is really great!

[AndyScherzinger]

merged to master for 1.5.0