Support two-level file extensions about sunflower-fm

[GoogleCodeExporter]

Hm, I'll see what I can do about it.

Original comment by MeanEYE.rcf on 25 May 2011 at 8:15

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

If it's going to be implemented, I suggest making an additional setting to 
switch between the "classic" view (with a single extension in the corresponding 
column) and the new one. As for me, I feel alright with the first one. =)

Original comment by [email protected] on 25 Oct 2011 at 10:36

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

We are still looking for automatic method to handle this. If possible I would 
like to avoid maintaining list of double extensions.

Original comment by MeanEYE.rcf on 25 Oct 2011 at 10:48

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Well, here is the idea how to automatically handle it from the scratch (created 
while reading issue description), even I see directly some issues regarding 
response(performance)
You can have download-able file with common structure which you will need to 
work with it then when handling extensions:
- There should be prepared separated project which will take care about 
extracting file extensions for example from sites like 
http://www.file-extensions.org, this file will be download-able via REST API as 
base64 or JSON object, pure file over http,ftp, or whatever, it depends... Or I 
can even try onetime data extract from the site, maybe ask them for this file 
to be exported might be also way.
- As soon as we are talking about thousands of records to handle which might be 
very time consuming and can impact user experience perspective, the structure 
in memory could be maintained by something like "heapq" module, or more 
precisely in sorted tree, in case of file.tar.gz SF will need to search in the 
heapq object for gz and tar, if found both found, show "tar.gz" as extension 
else ...

I feel that this idea might work and be really overkill, hehe :-)

On the other hand it can be then customized from the generic way to something 
better - the lookup will be done only for selected groups of extension like 
archivers, etc. so in case of name like "file.tar.sh" the lookup will not be 
done as soon as sh is not in the lookup extension group...

Original comment by [email protected] on 12 May 2013 at 11:22

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Why not use a Python implementation of the unix 'file' command[1][2]?
E.g. "file --mime-type --mime-encoding *" produces outputs like:

    snippets.txt:   text/x-c; charset=utf-8
    Work:           inode/directory; charset=binary
    test.gpg:       application/pgp-keys; charset=us-ascii
    text.rst:       text/plain; charset=us-ascii
    text.txt:       text/plain; charset=us-ascii
    text.pdf:       application/pdf; charset=binary
    text.odt:       application/vnd.oasis.opendocument.text; charset=binary

'file' can detect the real type of files, even with wrong extensions:

    $ file --mime-type --mime-encoding test.odt 
    test.odt: application/vnd.oasis.opendocument.text; charset=binary

    $ mv test.odt test.pdf
    $ file --mime-type --mime-encoding test.pdf
    test.pdf: application/vnd.oasis.opendocument.text; charset=binary


[1] http://en.wikipedia.org/wiki/File_(command)
[2] http://stackoverflow.com/a/1974737

Original comment by [email protected] on 23 May 2013 at 10:01

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Issue here is not detecting file type but rather distinguishing two level 
extensions like .tar.gz from file names containing dot like "03.03.2013.txt". 
Strictly speaking Linux doesn't have extensions, everything is just file name. 
Content of a file matters and that's that we care about.

Also, Sunflower does posses ability to detect file type based on extension and 
content itself. This issue is basically about what should end up in "Ext" 
column.

Original comment by MeanEYE.rcf on 23 May 2013 at 10:05

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks, now I understand. 
What is the need for the "Ext" column? Why not drop the "Ext" column and 
introduce a "Filetype" and/or "Mimetype" column?

Original comment by [email protected] on 23 May 2013 at 10:23

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

There's no need for Ext column and it can be disabled. Mimetype column is 
something we currently don't have but sounds interesting. Do you personally 
need it? And what do you think could be the benefit of having one?

Original comment by MeanEYE.rcf on 23 May 2013 at 10:24

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

> And what do you think could be the benefit of having one?

IMHO the general benefit would be a better user experience. Functional and 
technical
benefits could be:

    1. {File|Mime}type column replaces insufficient "Ext" column.
    2. File type column shows what a user can expect inside a specific file:
       text, picture, pdf ...
    3. Re-using standards like file, libmagic, freedesktop.org
    4. The file type could give hints about the file content to other functions   
       of sunflower e.g. 
       - to choose the preferred or default application to open the file[3],
       - to start the correct thumbnail application for the given type,
       - to show a specific icons per file type for files in the list.
    ...

[3] http://www.freedesktop.org/wiki/Software/pyxdg/

Original comment by [email protected] on 23 May 2013 at 10:55

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Sunflower already supports detecting file type based on content, I just don't 
see the purpose of having mime type column. We already have icons that reflect 
file type, also right clicking on file and selecting properties will allow you 
to change associated application with specific file type.

Original comment by MeanEYE.rcf on 23 May 2013 at 11:00

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Ouch, I totally misunderstand this issue and I am inexperienced with sunflower. 
Sorry for the noise.

Original comment by [email protected] on 23 May 2013 at 11:26

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

That's okay. :) Am glad we cleared that one out. It's not a noise, sometimes 
comments like these give me insight into what people need, are thinking about 
or expect to see from my program.

Original comment by MeanEYE.rcf on 23 May 2013 at 11:28

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I've added primitive support. Until I find a better solution.

Original comment by MeanEYE.rcf on 6 Aug 2014 at 11:22

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****