With more verbose logging server-side, there’s a ”Deprecated event type” followed by "Exception":"Sabre\\DAV\\Exception\\NotFound" for the file being uploaded. So it’s perhaps correctly reporting that the file (about to be uploaded) does not exist (yet), but for some reason the app receiving this message flips it around, thinking the file does exist, and thus reports a conflict.

Here’s a logcat snippet from another device. The result of ”Existence check” comes back as ”Name collision”, for any and all files.

This is still an issue, and always has been for Samsung devices with One UI’s scrolling screenshot feature.

In short

Since updating the Android app to 3.14.0 RC1 (and server to 20.0.1 earlier), I can not upload anything with the app. Desktop client still syncs just fine.

Steps to reproduce

Try to upload a file (either manually or by taking a photo for auto-upload)

Expected behaviour

File should get uploaded

Actual behaviour

There’s a notification about ”File upload conflict”. Selecting the notification results in ”Error creating conflict dialog”. Going to uploads view and selecting ”Resolve conflict” for a file just results in ”Sync conflict, please resolve manually”.

Can you reproduce this problem on https://try.nextcloud.com?

Trying to add an account in the app causes the app to crash.

Environment data

Android version: 10
Device model: Samsung Galaxy A9 (2018)
Stock or customized system: stock
Nextcloud app version: 3.14.0 RC1 (from Beta channel)
Nextcloud server version: 20.0.1
Reverse proxy: no

Logs

Web server error log

Nothing NC-related

Nextcloud log (data/nextcloud.log)

Nothing related to the uploads, just

• fread(): read of 8192 bytes failed with errno=21 Is a directory
• Undefined offset: 3

I was affected by this too, but I’m not using encryption:

# sudo -u www-data php occ encryption:status
  - enabled: false
  - defaultModule: OC_DEFAULT_MODULE

The server log just showed ServerNotAvailableException:"Could not decrypt key" for any connection attempts after 19->20 upgrade.

I have another instance where I am using encryption, and there I was able to log in just fine. I did some diffing and found the working installation (with encryption enabled) had 'encryption.legacy_format_support' => true,, while the non-working installation (with encryption disabled) didn’t. Adding that to my config.php alone didn’t fix the issue, so I also added 'encryption.key_storage_migrated' => false, and after that I was able to log in again.

According to documentation, starting with version 20 the legacy encryption is off by default. occ encryption:scan:legacy-format is supposed to tell whether you can disable the compatibility mode, but for the instance without encryption it seems to produce a false positive (complete with a typo):

All scanned files are propperly encrypted. You can disable the legacy compatibility mode.

For the admin user, the now otherwise working, unencrypted instance also shows a ”Please enable server side encryption in the admin settings in order to use the encryption module” notification in the web UI, for every page load (i.e. even after dismissal it just pops back up whenever I navigate in the UI).

The errors reported by app:check-code encryption are probably unrelated, as the same errors are reported for both my instances.

Kaakkurin liikuntamaa. En ole käynyt, mutta ”alueella on laajat maastopyöräilyreitistöt. Reittejä on kolmea eri tasoa: helppoja, keskivaikeita ja vaikeita.”

Happy to see the plugin get a new lease on life from an active and engaged developer. I only use a small portion of the features (suggested local tags), but this features alone makes it one of the most useful plugins for me.

Thanks for keeping Simple Tags alive!

Simple Tags is great in picking exact local tag matches from the post text, but with Finnish (and probably some other languages as well), inflection often causes it to miss relevant suggestions (from Local tags). For instance, when using the inessive case ”Helsingissä” in the post, Simple Tags won’t suggest (previously added local tag) ”Helsinki”.

A fuzzy matching feature would help here.

While Simple Tags’ future was in limbo, I tested some other plugins, and one of them (maybe Smart Tag Insert) had such a feature: it showed related tags using some kind of fuzzy matching. I have no idea how difficult this feature would be to incorporate into Simple Tags though.

I know I can show all tags with the ”Click tags” feature, but with close to 2000 pre-existing tags, the full list is quite unwieldy.

This doesn’t work with hidden files in Bash, unless you shopt -s dotglob first.

The version I’m using:

yle-dl 20200807 with wget 1.20.3 (in Ubuntu 20.04)

Steps to reproduce:

$ /usr/local/bin/yle-dl -qq --backend wget --wget /usr/bin/wget https://areena.yle.fi/1-50636796

What I expect to happen:

For the download to complete without any output in the terminal.

What happens instead:

The command outputs this line (which to me seems like is from wget):

2020-09-25 17:25:27 URL:https://ylekaod-a.akamaihd.net/s/p/1955031/sp/195503100/serveFlavor/entryId/1_ldivkmki/v/11/ev/2/flavorId/1_b6wtzy8f/name/a.mp3?__hdnea__=st=1601043921~exp=1601058321~acl=/s/p/1955031/sp/195503100/serveFlavor/entryId/1_ldivkmki/v/11/ev/2/flavorId/1_b6wtzy8f/name/a.mp3*~hmac=bddcd801a98d3560990842beccee528da3861e588cf3438880642267aab03dc4 [21436961/21436961] -> "Kaverin puolesta kyselen: Koppuraiset kalsarit ja muita deittimokia-2020-09-25T06:45.mp3" [1]