Describe the bug
The files option is greyed out and I don't know why.
Steps To Reproduce:
Expected behavior
I should be able to browse the files of my device. Everything's configured on my phone and it used to work. At least something should tell me why it's disabled.
Screenshots
Can't take a screenshot because that crashes wayland
Support Log
(Where is the log stored? The "Review log" button attempts to open it in Totem unfortunately)
System Details (please complete the following information):
GSConnect environment (if applicable):
_Totem_?!!? Well, that's a new one!
The GSConnect log isn't stored anywhere on disk, everything goes to the systemd journal -- what happens is, when you start data collection for a report, GSConnect switches into debug mode and greatly increases its log output over normal levels. So, while the dialog is open, every action will produce detailed logs, which are also collected for review.
When you hit the review button, it's _supposed_ to open your default text editor with the log messages that were collected. They'd be loaded from a temp file, though, if they're saved to disk at all. But since that's not working, you could just run journalctl -e from your user account (without sudo) to view the user journal starting from the end (the most recent logs). Everything collected would be there as well.
You may still want to double-check your default text editor settings as well, though. 馃槈
(Regarding the central question of why Files would be grayed out... honestly I didn't know that it _could_ be grayed out. @andyholmes made some changes to how GSConnect interfaces with Gvfs to handle the SSH connections for remote file browsing, this may be new behavior related to that -- either intentional or unintentional.)
Oh! Didn't even think about checking the journal. Is there anything I can do to trigger some sshfs check? Because right now it's only showing soundcard info :)
@skerit
And those messages might not even be ours.
Unfortunately, in terms of the SSH setup we're largely at the mercy of Gvfs, which tends not to be particularly forthcoming. So, SSH logging is unfortunately rather poor. (On _both_ ends. The KDE Connect app's ssh logging is just as anemic, and plenty of several users have set up adb debugging connections to trace the Android side of the process only to come back with similar reports: "OK, well, when this fails it logs the exact same nothing as when it succeeds."
The lack of logging is irritating, especially since commandline ssh can produce _extremely_ (even excessively) verbose traces of its negotiations with the other end of the link.
But in thinking about it, what I _can't_ say is whether that output is free of sensitive information regarding things like ciphers, private key details, data about the user identity on either the remote or local host, etc.
i would not be at all surprised if the verbose trace output produced by libssh is not sanitized enough to store it in persistent logs (or sanitized at all, really). Which would make it unsuitable for logging, as doing so would create a security vulnerability merely by making those details accessible to anyone who can view the logs. Not an ideal situation either way, of course.
It's hard to say why this has happening, but a greyed out menu probably means there are no items in the Files submenu. It's pretty unlikely that would happen, but you might want to double-check the Android app has a directory configured.
In master we no longer rely on the remote device to report these directories and instead enumerate them automatically, but that change hasn't been well tested and isn't in v41. If you want, you can test the current state of master (Instructions):
Other than that, there weren't any drastic changes between v39 and v41 (diff) and the only change that seems related is this:
@@ -359,7 +363,8 @@ var Plugin = GObject.registerClass({
filesItem.set_label(_('Files'));
filesItem.set_submenu(filesSubmenu);
- this.device.replaceMenuAction('device.mount', filesItem);
+ let index = this.device.removeMenuAction('device.mount');
+ this.device.addMenuItem(filesItem, index);
} catch (e) {
logError(e);
}
This was pretty much what replaceMenuAction() did, so I don't see that could've caused the problem.
Should be fixed in v42, please feel free to re-open if the issue persists.
Most helpful comment
_Totem_?!!? Well, that's a new one!
The GSConnect log isn't stored anywhere on disk, everything goes to the systemd journal -- what happens is, when you start data collection for a report, GSConnect switches into debug mode and greatly increases its log output over normal levels. So, while the dialog is open, every action will produce detailed logs, which are also collected for review.
When you hit the review button, it's _supposed_ to open your default text editor with the log messages that were collected. They'd be loaded from a temp file, though, if they're saved to disk at all. But since that's not working, you could just run
journalctl -efrom your user account (withoutsudo) to view the user journal starting from the end (the most recent logs). Everything collected would be there as well.You may still want to double-check your default text editor settings as well, though. 馃槈