html file detected as unknown application/octet-stream

[chicoff]

On ubuntu 20.04, when I mount an sftp or ftp share with nautilus (1:3.36.1-1ubuntu1), html files are not detected. The properties dialog shows "Unknown (application/octet-stream)". Php, css and js files are right detected. It is a known bug?

No problem with pcmanfm.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: nautilus 1:3.36.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-18.22-generic 5.4.24
Uname: Linux 5.4.0-18-generic x86_64
NonfreeKernelModules: talpa_vfshook talpa_pedconnector talpa_pedevice talpa_vcdevice talpa_core talpa_linux talpa_syscallhook
ApportVersion: 2.20.11-0ubuntu21
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Mar 31 14:59:58 2020
InstallationDate: Installed on 2019-12-18 (103 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
SourcePackage: nautilus
UpgradeStatus: Upgraded to focal on 2020-03-20 (10 days ago)
usr_lib_nautilus:

[Sebastien Bacher (seb128)]

Thank you for your bug report, that's indeed a known issue upŝtream and bug worked on
https://gitlab.gnome.org/GNOME/nautilus/-/issues/1425

[Launchpad Janitor (janitor)]

This bug was fixed in the package nautilus - 1:3.36.1.1-1ubuntu1

---------------
nautilus (1:3.36.1.1-1ubuntu1) focal; urgency=medium

  * New upstream version
  * debian/patches/git_remote_content.patch:
    - get the correct mimetype for files on remote locations (lp: #1869881)

 -- Sebastien Bacher <email address hidden> Mon, 06 Apr 2020 12:35:43 +0200

[chicoff (chicoff)]

With nautilus - 1:3.36.1.1-1ubuntu1, the file is right detected as html, but is not possible to open the file direct with the associated text editor (vscode). It opens a dialog with this message: "there is no application installed for html documents"

[Florent Mertens (givre)]

Same issue here with text-like files. The .txt files are now correctly recognized as text files and are open with a text editor by default, but the other configuration files which are not .txt ending, like in my case .parset file, show the issue described by chicoff. Also I set manually an application to open this kind of file, and the application appears in the right-click menu, it does not launch when I select it / press enter / double click on it on the icon. I have to go to "Open with other application" and select the app so that finally I can open the file.

[Sebastien Bacher (seb128)]

Thanks for the new comment, did those scenarios worked in previous Ubuntu releases? I've shared the new comments on the upstream bug

[Florent Mertens (givre)]

As far as I remember, yes it used to work (after having an application manually set for the file extension).

[chicoff (chicoff)]

Yes bot scenarios worked with 18.04 and 19.10 with SFTP mounts. With FTP mounts I had a similar behaviour like with nautilus - 1:3.36.1.1-1ubuntu (file correctly recognized but not openend)

[Sebastien Bacher (seb128)]

The file opening issue is another one, it has also been fixed upstream now
https://gitlab.gnome.org/GNOME/glib/-/commit/35953b5
which is in 2.64.2

[Sebastien Bacher (seb128)]

The new glib has been uploaded to focal-proposed now which includes the other fix

[chicoff (chicoff)]

perfect now it works!

[Matifou (matthieu-stigler)]

Hi

I am still experiencing the problem! Creating a .whatever file, it opens directly in gedit, using nautilus on a local drive. Doing exactly the same using nautilus on a sftp, it will:

1) Complain file of unknown type
2) Clicking "select applications" will not suggest any default application, so need to click on View all Applications. Then selecting gedit will open once.
3) Not remember any choice, so every time I close gedit and try to reopen, problem 1) and 2) occur.

When was the bug thought to be fixed? I have:

$nautilus --version:
 GNOME nautilus 3.36.3
$apt list libglib2.0-bin
 Listing... Done
 libglib2.0-bin/focal-updates,now 2.64.3-1~ubuntu20.04.1 amd64 [installed,automatic]
 libglib2.0-bin/focal-updates 2.64.3-1~ubuntu20.04.1 i386

Thanks!

[Sebastien Bacher (seb128)]

@Matifou, the issue you describe is a different one and probably not a bug. The type detection on remote location rely on the filename usually because to guess from the content it would have to start downloading the files which could be slow or expensive.