Recognize further file extensions as text files (to be opened in the "in-app" text editor)

[AndyScherzinger]

This is a clone of nextcloud/android#1756 which asked for further file extensions to be opened in the Android client's in-app viewer. So for consistency reasons if this is to be implemented it should be implemented across the eco system as-in webUI and clients (at least Android and iOS)

Expected behaviour

1. Create a file text with extension .adoc, .rc, .conf, .gitignore, .todo, .cfg, or without any extension
2. Click on the file
3. File opens in the webUI text editor

Actual behaviour

.adoc, .rc, .conf, .gitignore, .todo, .cfg are treated as generic file

Environment data

Android version: 5.1.1

Stock or customized device OS: Customized

Nextcloud Android app version: 2.0.1, from FDroid

Nextcloud server version: 12

[MorrisJobke]

@icewind1991 @rullzer Ideas for this?

[j-ed]

Wouldn't be possible to automatically identify the file type based on its mime-type instead of pinning it to file extensions? It was a common trick in the past to fake a file extension to bypass email block list etc.
See: https://stackoverflow.com/questions/457797/best-way-to-recognize-a-filetype-in-php

[MorrisJobke]

Wouldn't be possible to automatically identify the file type based on its mime-type instead of pinning it to file extensions? It was a common trick in the past to fake a file extension to bypass email block list etc.

The fileinfo command is used as fallback, because it is usually a lot slower and the file needs to be loaded into memory for this. Thus it is not that performant if you need to detect the mime type for a lot of files in a batch. But for uploads this should be fine. On the other side it is then bad to use one approach for file uploads but another one for files:scan. 😕

cc @icewind1991

[j-ed]

@MorrisJobke Thank you for the explanation. I agree, for uploading single files it might be justified to spend that additional time to evaluate the correct mime-type but for batch runs it might be better to rely on the database information or a different approach need to be find.
Due to the fact that all kind of house keeping tasks are running in the background of Nextcloud, wouldn't it make sense to also double-check the mime-type of newly added files by e.g. executing the external file-command. The command is relatively fast and could also run on whole directories - just an idea.

[AndyScherzinger]

But for uploads this should be fine. On the other side it is then bad to use one approach for file uploads but another one for files:scan.

Besides that looking at the client we do not receive mime type information from the server that is why the clients also rely on the file extension to predict the mime type.

[j-ed]

@AndyScherzinger From what I've seen mime type information exist for all files on the server. Wouldn't it make sense to enhance the used API so that that piece of information is transferred too?

[AndyScherzinger]

@j-ed can't tell for the server part and yes having this info transferred from the server would help since we could (to some extend) drop mime-type calculation on the client(s) afaik the mime type information (at least via file extension) is the same on webUI and Android client. So if the webUI thinks a file is text-based than the Android client should do so too (if file extension based of course).

[tobiasKaminsky]

Besides that looking at the client we do not receive mime type information from the server that is why the clients also rely on the file extension to predict the mime type.

We do get the mimetype:
Getting from webdav to RemoteFile:
https://github.com/nextcloud/android-library/blob/master/src/com/owncloud/android/lib/resources/files/ReadRemoteFolderOperation.java#L167

From RemoteFile to OCFile:
https://github.com/nextcloud/android/blob/8fef61ea93fb1307d431de1d594b473f1f6e4b2d/src/main/java/com/owncloud/android/utils/FileStorageUtils.java#L222-L222

Were do we rely on the file extension? Maybe only on local files?

[AndyScherzinger]

Were do we rely on the file extension? Maybe only on local files?

We always do for Android, see FileListListAdapter for example

[tobiasKaminsky]

Then we should adapt this: use mimeType from server as often as possible and rely on the extension only as fallback.

[AndyScherzinger]

Sounds good to me for Android 👍

@nextcloud/ios how is this handled in the iOS client?

[marinofaggiana]

I use the UTI, but if possible the mimeType from server is better !

[Spartachetto]

I hope not to derail the discussion but, as you are considering to extend the files recognized as some that could be open via text editor, I'd like to remember the proposal of other extensions.

Look here (nextcloud/files_texteditor#16) and here (nextcloud/files_texteditor#15) for different syntax files which could be nice to open.

Thank you

[szaimen]

I'm closing this issue due to inactivity. Please reopen if you still want to implement this.

[szaimen]

I was at least able to open .conf files with the built in text editor. So I think this is at least partially implemented.

[tobiasKaminsky]

Also on Android with built in text editor?

[szaimen]

Yes

[szaimen]

Tough I wonder why this is in the server repository if it is an android ticket? 🤔

[Spartachetto]

@szaimen this issue pops out several times in seemingly unrelated subjects.
I think that even the discussion in Text app about non destructive editing (nextcloud/text#439 ) could be considered as related.