Attachments viewer - wrong file type detected

Help / Discuss
#1

Here’s a strange problem with the attachment pane at the bottom of wiki page.

I’ve attached a number of files with an extension of DRF, which is basically a text file with information system to tell a document management system (OpenText DocsDM) which file to open.

The format of the file is just a single line of text containing a couple of fields seperated by ; characters.

When I attach these files to xwiki, xwiki detects them as image files

19

The above screenshot shows a “broken link”. Inspecting the element shows the following:

<span class="mime" data-type="image/x-raw-kodak">
  <span title="Image">
    <img src="/xwiki/bin/download/Main/01%20Marketing%20Materials%20and%20Knowhow/01%20General%20Information/WebHome/CHARLTONS-100557.PPT.DRF?width=48" alt="CHARLTONS-100557.PPT.DRF">
  </span>
</span>

Clearly this isn’t an image file.

Is there a way to override the detected file type?

I’ve run the 1.17 tika-app file detection on this file and it returns “text/plain” which is more sensible than a raw kodak image file.

Any suggestions?

#2

Would need to debug what happen exactly but XWiki definitely get this information from Tika by default if those files were attached using standard UI. I guess the first thing I would check is which mimetype has been stored for those files in the xwikiattachment table. If there is none then it means those files did not went trough the standard attachment UI and that the content type is decide by the application server usually (AFAIR).

#3

This HTML:

<span class="mime" data-type="image/x-raw-kodak">
  <span title="Image">
    <img src="/xwiki/bin/download/Main/01%20Marketing%20Materials%20and%20Knowhow/01%20General%20Information/WebHome/CHARLTONS-100557.PPT.DRF?width=48" alt="CHARLTONS-100557.PPT.DRF">
  </span>
</span>

is generated by https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-flamingo/xwiki-platform-flamingo-skin/xwiki-platform-flamingo-skin-resources/src/main/resources/flamingo/attachment_macros.vm#L64

<span class="mime" data-type="$!escapetool.xml($attachment.mimeType)">
  #if ($attachment.isImage())
    <span title="$escapetool.xml($services.localization.render('core.viewers.attachments.mime.image'))">
      <img src="$xwiki.getURL($attachmentReference, 'download', 'width=48')"
        alt="$escapetool.xml($attachment.filename)"/>
    </span>
  #else
    #mimetypeimg($attachment.mimeType.toLowerCase() $attachment.filename.toLowerCase())
  #end
</span>

which means:

  • $attachment.mimeType = image/x-raw-kodak
  • $attachment.isImage() = true (which is expected considering the mime type)
  • file name is CHARLTONS-100557.PPT.DRF

If you check https://en.wikipedia.org/wiki/Raw_image_format#Raw_filename_extensions_and_respective_camera_manufacturers you’ll see:

.dcs .dcr .drf .k25 .kdc (Kodak)

so .drf is a file extension used by Kodak raw image format .

#4

Hi tmortagne,

then that would appear to not be the case - when I compare with using the tiki-app.

Also, I’ve looked in the xwikiattachment table and discovered something interesting:

| -1531974419 | 747481590514627793 | CHARLTONS-114916.DOC.DRF | 25 | 25 | NULL | 2018-03-19 18:01:12 | XWiki.pdwalker | 1.1 | | file | file |
| -854668849 | 6029613195908338096 | CHARLTONS-78190.DRF | 24 | 24 | image/x-raw-kodak | 2018-03-19 15:10:49 | XWiki.user1 | 1.1 | | file | file |

The first attachment was uploaded by editing a hyperlink in the editor, selecting “Attachment” under Link Info, then selecting the file under the Upload tab and the clicking “send it to the server”

The second attachment was uploaded using the //url/page?viewer=attachments and clicking on the “Choose files button” and then selecting it as one of multiple files. (I haven’t tried with just uploading a single file this way)

However, both attachments are treated as Kodak raw image files when looking at the image tab.

#5

Hi mflorea,

Yes, I am aware that DRF extension is considered a Kodak raw image format. However, I was expecting that with the use of the Tika libraries, that the system would detect that it is not actually an image file but a text file and treat it appropriately. Instead it appears to be just examining the extension without examining the content.

Also, if I were to update the content type in the xwikiattachment table to text/plain for these attachments - would this work around my problem?

#6

Yes. One of the ideas behind allowing to store the mimetype was to force some mime type instead of the automatic one.

#7

I’ll test that now.

#8

Yes, that’s fixed my current problem.

I also restarted xwiki, just in case of caching causing an issue. Next I’ll test that change without restarting xwiki.

Please note that there is still a potential problem - there are two different upload paths, one of which assigns a mimetype to the attachment and a second which assigns a mimetype of “null”. You may wish to investigate that.