Ah, apparently ”Show content warnings” on the app is the opposite of what’s ”Always expand posts marked with content warnings” in the web UI. I was confused because the former refers to the warning, whereas the latter refers to the content. There may be minor usability issue there, but I’ll leave it out of this one.

Sorry for the noise. To make up for it, #290 looks like a duplicate of this one and thus could possibly also be closed.

I have ”Always expand posts marked with content warnings” on in my settings, but CW-marked posts in the Android app still show as unexpanded.

I’m fairly sure this used to work until recently, and #87 being closed as ”completed” back in October would imply I wasn’t just imagining it.

What is the problem you are having with rclone?

I’m using a crypt-on-sftp remote, which was working just fine up until v1.65.2. With v1.66, attempts to sync to it now fail with ”optional feature not implemented”. I’ve not narrowed down whether it’s the crypt or the sftp layer, so I’m just reporting my (failing) test case below.

I did a bisect, and apparently this issue came in at f5f8678 (which was a fix for #6685).

What is your rclone version (output from rclone version)

1.66.0

Which OS you are using and how many bits (e.g. Windows 7, 64 bit)

Ubuntu 22.04 (64-bit)

Which cloud storage system are you using? (e.g. Google Drive)

sftp

The command you were trying to run (e.g. rclone copy /tmp remote:tmp)

rclone sync a/ C:

Steps to reproduce

1. rclone --config test.conf config
2. set up sftp (44) remote called S
   • for test purposes here I’m using localhost as the underlying remote server
   • set user & password
   • leave everything else at defaults
3. set up crypt remote C, with
   • ”S:ftp” as the underlying remote
   • Very simple filename obfuscation (obfuscate)
   • Encrypt directory names (true)
   • set password, no password2
4. mkdir -p ftp a/b # on the sftp remote; here I'm using localhost
5. touch a/test1 # on the sftp remote
6. rclone --config test.conf sync a/ C: -vv # no problems
7. touch a/b/test2 # on the sftp remote
8. rclone --config test.conf sync a/ C: -vv

A log from the command with the -vv flag (e.g. output from rclone -vv copy /tmp remote:tmp)

2024/03/12 14:33:36 DEBUG : rclone: Version "v1.66.0" starting with parameters ["rclone" "--config" "test.conf" "sync" "a/" "C:" "-vv"]
2024/03/12 14:33:36 DEBUG : Creating backend with remote "a/"
2024/03/12 14:33:36 DEBUG : Using config file from "/home/jani/test.conf"
2024/03/12 14:33:36 DEBUG : fs cache: renaming cache item "a/" to be canonical "/home/jani/a"
2024/03/12 14:33:36 DEBUG : Creating backend with remote "C:"
2024/03/12 14:33:37 DEBUG : Creating backend with remote "S:ftp"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: New connection 127.0.0.1:48814->127.0.0.1:22 to "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Shell type "unix" from config
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Relative path resolved to "/home/jani/ftp"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Using root directory "/home/jani/ftp"
2024/03/12 14:33:37 DEBUG : test1: Size and modification time the same (differ by -995.288851ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : test1: Unchanged skipping
2024/03/12 14:33:37 DEBUG : b/test2: Need to transfer - File not found at Destination
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for checks to finish
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for transfers to finish
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Shell path "/home/jani/ftp/98.g/149.zkyz4.EACoEuq1.vgxzogr"
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Running remote command: md5sum /home/jani/ftp/98.g/149.zkyz4.EACoEuq1.vgxzogr
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Remote command result: ac83867dee807f03ee4f8f307cda1257  /home/jani/ftp/98.g/149.zkyz4.EACoEuq1.vgxzogr
2024/03/12 14:33:37 DEBUG : 98.g/149.zkyz4.EACoEuq1.vgxzogr: Parsed hash: ac83867dee807f03ee4f8f307cda1257
2024/03/12 14:33:37 DEBUG : b/test2.yuwiyok9.partial: md5 = ac83867dee807f03ee4f8f307cda1257 OK
2024/03/12 14:33:37 DEBUG : b/test2.yuwiyok9.partial: renamed to: b/test2
2024/03/12 14:33:37 INFO  : b/test2: Copied (new)
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting files as there were IO errors
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting directories as there were IO errors
2024/03/12 14:33:37 ERROR : Attempt 1/3 failed with 1 errors and: optional feature not implemented
2024/03/12 14:33:37 DEBUG : test1: Size and modification time the same (differ by -995.288851ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : test1: Unchanged skipping
2024/03/12 14:33:37 DEBUG : b/test2: Size and modification time the same (differ by -116.891668ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : b/test2: Unchanged skipping
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for checks to finish
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for transfers to finish
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting files as there were IO errors
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting directories as there were IO errors
2024/03/12 14:33:37 ERROR : Attempt 2/3 failed with 1 errors and: optional feature not implemented
2024/03/12 14:33:37 DEBUG : test1: Size and modification time the same (differ by -995.288851ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : test1: Unchanged skipping
2024/03/12 14:33:37 DEBUG : b/test2: Size and modification time the same (differ by -116.891668ms, within tolerance 1s)
2024/03/12 14:33:37 DEBUG : b/test2: Unchanged skipping
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for checks to finish
2024/03/12 14:33:37 DEBUG : Encrypted drive 'C:': Waiting for transfers to finish
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting files as there were IO errors
2024/03/12 14:33:37 ERROR : Encrypted drive 'C:': not deleting directories as there were IO errors
2024/03/12 14:33:37 ERROR : Attempt 3/3 failed with 1 errors and: optional feature not implemented
2024/03/12 14:33:37 INFO  : 
Transferred:   	         32 B / 32 B, 100%, 0 B/s, ETA -
Errors:                 1 (retrying may help)
Checks:                 5 / 5, 100%
Transferred:            1 / 1, 100%
Elapsed time:         0.3s

2024/03/12 14:33:37 DEBUG : 15 go routines active
2024/03/12 14:33:37 DEBUG : sftp://jani@localhost:22/ftp: Closing 1 unused connections
2024/03/12 14:33:37 Failed to sync: optional feature not implemented

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don’t comment if you have no relevant information to add. It’s just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

@amyblais Alright, I finally managed to get through the signup. Here’s my suggestion, although it’s in moderation for now, so the link probably won’t work until it’s approved.

Hi @amyblais,

I could post this on the feature idea forum, but I can’t figure out how the signup on the site works. When I click on ”Create an account”, I get a prompt to verify my email address, and having done that, a page saying ”Go back to Production to finish logging in”. I don’t know what ”Production” is, and at no point was there any actual way to set up a password, so I can’t log in.

Summary

A ”Mark read” choice in push notifications about new messages, as seen in many IM apps, would be handy in Mattermost Mobile too. Currently the message can only be marked read by tapping the message to open the app (which is slow).

Environment Information

• Device Name: Samsung Galaxy A9
• OS Version: Android 10
• Mattermost App Version: 2.11.0
• Mattermost Server Version: 9.3.0

Steps to reproduce

1. Receive a message notification on the Android app.
2. Pull down the notifications.
3. Expand the received notification.

Expected behavior

Have a ”Mark read” option underneath the expanded notification.

Observed behavior

No ”Mark read” option, only ”Reply”.

I was on my Android device, saving URLs pointing to individual comments in threads at Ubiquiti’s Unifi forums, but later returning to them on my desktop realized that the hash (fragment) portion had been dropped, so that the URLs only pointed to the opening post. Hence, just one link (pointing to the first post) had been saved. This is pretty useless for threads spanning multiple pages, where finding an individual comment is tough without the exact link.

Here’s a (random) example of a URL pointing to the second comment on the third page of one thread. Sharing it from any of Android, iPhone or desktop results in a link pointing to the first post instead.

Sounds good to me!

To correct myself, it looks like the default for the WP plugin is to federate the full content, whereas I’ve opted to just use the excerpt, so assuming most other users don’t change the default, their followers do get the full post content inside the app. I don’t know if that still includes the link back to the blog, but then it’s less of an issue if the link doesn’t go to a browser (even though the reloading behavior may still look a bit confusing).

Thank you for the workaround!

I can see the appeal of staying inside the app, and would usually prefer it myself too, but cases like this do challenge the usefulness of that model.

FWIW, I’ve not come across posts from other sites exhibiting this yet, but then again I’m not following many WP blogs, and I suspect the issue could be prevalent there, as my settings for the ActivityPub plugin are pretty much at defaults.

I’m using the ActivityPub plugin to enable following posts from my WordPress blog. The posts federate as excerpts with a URL pointing to the full post on my site.

Tapping on that URL in the Android app only causes it to reload the post (excerpt) inside the app, instead of opening the URL in either webview or a browser as I’d expect it to.

The (official) IOS app does open the URL a browser, as does Firefox on the desktop, which is why I suspect the Android app being at fault here.

I don’t know of a way to link my blog here it so that it opens in the app (which is a bit ironic), but here’s a deck link to the federated posts on mastodon.social. My personal Mastodon account is on mastodon.social.

Both my Android phone and Android tablet are affected, both are on Mastodon version 2.2.1. The phone is running Android 10 (with Samsung’s One UI 2.0), the tablet is on Android 11 (One UI 3.1).

Below is a screen recording from the Android phone exhibiting the issue: the first tap of the URL opens the federated note in single view, and subsequent taps then just reload that same view.