Using LibreOffice together with Alfred on my Mac the .odf are not showing up in the search results. This could be related to "LibreOffice not exporting the correct UTI types" For more details please take a look here. https://getsatisfaction.com/alfredapp/topics/_odf_files_not_showing_in_document_search?utm_content=topic_link&utm_medium=email&utm_source=reply_notification i'm not a dev so!
Do you reproduce this with a brand new file ? BTW, I wanted to post this : " I'm trying to reproduce the bug but I've got fewer elements returned by mdls on new files (an odf and an ods file). For example, there's no kMDItemContentTypeTree. I'm mainly use Linux and I know very little about Mac, could anybody give me advice ? " but it needed an account and I didn't want to create one. The weird thing is everything seems there (I compared ods and odf declarations) when we look at http://opengrok.libreoffice.org/xref/core/sysui/desktop/macosx/Info.plist but perhaps I missed something.
Created attachment 61810 [details] Test .odt file used.
@Julien tnx for looking into this, i'm not a dev but willing to help out where i can. I created a brand new test file and ran a new mdls i attached the test.odt to this page. Let me know if you have additional questions. mdls test.odt kMDItemContentCreationDate = 2012-05-18 16:48:11 +0000 kMDItemContentModificationDate = 2012-05-18 16:48:11 +0000 kMDItemContentType = "org.oasis-open.opendocument.text" kMDItemContentTypeTree = ( "org.oasis-open.opendocument.text", "public.data", "public.item", "public.content" ) kMDItemDateAdded = 2012-05-18 16:48:11 +0000 kMDItemDisplayName = "test.odt" kMDItemFSContentChangeDate = 2012-05-18 16:48:11 +0000 kMDItemFSCreationDate = 2012-05-18 16:48:11 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = 0 kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = 0 kMDItemFSLabel = 0 kMDItemFSName = "test.odt" kMDItemFSNodeCount = 8514 kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = 8514 kMDItemFSTypeCode = "" kMDItemKind = "OpenDocument Text" kMDItemLastUsedDate = 2012-05-18 16:48:12 +0000 kMDItemLogicalSize = 8514 kMDItemPhysicalSize = 12288 kMDItemUseCount = 2 kMDItemUsedDates = ( "2012-05-17 22:00:00 +0000" )
You created an odt file but you said that the pb was with odf file. Could you create a new odf file and give the results of mdls on it ? As for me, I don't have anything for kMDItemContentTypeTree or kMDItemContentType when I launch mdls on your file. Perhaps I must configure Spotlight before.
This was new file, what's PB?
(In reply to comment #5) > This was new file, what's PB? There's no pb with your file, the pb is my lack of knowledge with Macos world. I don't know why mdls doesn't show the 2 attributes I quoted. Anyway, as I said, it could be useful you give mdls results from a ods file + mdls results from a odf file to compare.
Created attachment 61826 [details] Test .ods file used
I ran an mdls on a .ods mdls test.ods kMDItemContentCreationDate = 2012-05-19 08:53:52 +0000 kMDItemContentModificationDate = 2012-05-19 08:53:52 +0000 kMDItemContentType = "org.oasis-open.opendocument.spreadsheet" kMDItemContentTypeTree = ( "org.oasis-open.opendocument.spreadsheet", "public.data", "public.item", "public.content" ) kMDItemDateAdded = 2012-05-19 08:53:52 +0000 kMDItemDisplayName = "test.ods" kMDItemFSContentChangeDate = 2012-05-19 08:53:52 +0000 kMDItemFSCreationDate = 2012-05-19 08:53:52 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = 0 kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = 0 kMDItemFSLabel = 0 kMDItemFSName = "test.ods" kMDItemFSNodeCount = 7271 kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = 7271 kMDItemFSTypeCode = "" kMDItemKind = "OpenDocument Spreadsheet" kMDItemLastUsedDate = 2012-05-19 08:53:53 +0000 kMDItemLogicalSize = 7271 kMDItemPhysicalSize = 8192 kMDItemUseCount = 2 kMDItemUsedDates = ( "2012-05-18 22:00:00 +0000" ) Allards-MacBook-Pro:desktop Allards$
ODF mdls test.odf kMDItemContentCreationDate = 2012-05-19 08:57:50 +0000 kMDItemContentModificationDate = 2012-05-19 08:57:53 +0000 kMDItemContentType = "org.oasis-open.opendocument.formula" kMDItemContentTypeTree = ( "org.oasis-open.opendocument.formula", "public.data", "public.item", "public.content" ) kMDItemDateAdded = 2012-05-19 08:58:12 +0000 kMDItemDisplayName = "test.odf" kMDItemFSContentChangeDate = 2012-05-19 08:57:53 +0000 kMDItemFSCreationDate = 2012-05-19 08:57:50 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = 0 kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = 0 kMDItemFSLabel = 0 kMDItemFSName = "test.odf" kMDItemFSNodeCount = 4610 kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = 4610 kMDItemFSTypeCode = "" kMDItemKind = "OpenDocument Formula" kMDItemLastUsedDate = 2012-05-19 08:57:54 +0000 kMDItemLogicalSize = 4610 kMDItemPhysicalSize = 8192 kMDItemUseCount = 3 kMDItemUsedDates = ( "2012-05-18 22:00:00 +0000" )
Created attachment 61827 [details] Test .odf file used
Created attachment 61828 [details] Test .odg file used
Created attachment 61829 [details] Test .odp file used
Allards has answered all questions (thank you very much!), therefore the NEEDINFO status is not appropriate. But I can not confirm this issue right now, therefore I reset it to UNCONFIMED, sorry! This has some advantage: at least UNCONFIRMED bugs will not be closed after some time, so this status is better than NEEDINFO ;-)
Someone forgot to post the answer from Alfred team here (https://getsatisfaction.com/alfredapp/topics/_odf_files_not_showing_in_document_search?utm_content=topic_link&utm_medium=email&utm_source=reply_notification): The kMDItemContentTypeTree is missing "org.oasis-open.opendocument" which should be there as listed here: http://en.wikipedia.org/wiki/OpenDocument in the "UTI conforms to" section and... http://www.escape.gr/manuals/qdrop/UTI.html in the "conforms to" These could be missing on your mac due to a bug in LibreOffice not exporting the correct UTI types so it may be worth raising an issue with them? It is the "org.oasis-open.opendocument" classification which is required for a 'document' classification as far as Alfred is concerned as this covers all open doc types.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team
So, Alfred (currently at version 2) is a third party search tool. As OSX Finder allows one to search for ODF documents (both in terms of filename and content strings), why should we be bothered about this third party tool ? I would be tempted to mark this as NOTOURBUG or WONTFIX, unless it can still be shown that it is LibreOffice's fault - which doesn't appear to be the case, at least for Finder.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
According to comment #14 the LibreOffice files are missing "org.oasis-open.opendocument" from the kMDItemContentTypeTree, and I see the mdls logs posted don't have them When I run mdls on my mac on the test files here, they are present now This is in fact set by the Spotlight importer, so this has been resolved, but was not a bug in LibreOffice https://developer.apple.com/library/content/documentation/CoreServices/Reference/MetadataAttributesRef/Reference/CommonAttrs.html kMDItemContentType Uniform Type Identifier of the file. For example, a jpeg image file will have a value of public.jpeg. The value of this attribute is set by the Spotlight importer. Changes to this value are lost when the file attributes are next imported. This attribute is marked as nosearch. You must specify this attribute key explicitly in a query in order for its contents to be searched. Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 2; OS: Mac OS X 10.12.6; UI render: default; Locale: en-US (en_US.UTF-8); Calc: group mdls test2.odf _kMDItemOwnerUserID = 501 kMDItemContentCreationDate = 2017-08-26 15:58:48 +0000 kMDItemContentModificationDate = 2017-08-26 15:58:48 +0000 kMDItemContentType = "org.oasis-open.opendocument.formula" kMDItemContentTypeTree = ( "org.oasis-open.opendocument.formula", "org.oasis-open.opendocument", "public.data", "public.archive", "public.item", "public.content", "public.zip-archive", "org.oasis-open.opendocument.formula", "com.pkware.zip-archive" ) kMDItemDateAdded = 2017-08-26 15:58:48 +0000 kMDItemDisplayName = "test2.odf" kMDItemFSContentChangeDate = 2017-08-26 15:58:48 +0000 kMDItemFSCreationDate = 2017-08-26 15:58:48 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = (null) kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = (null) kMDItemFSLabel = 0 kMDItemFSName = "test2.odf" kMDItemFSNodeCount = (null) kMDItemFSOwnerGroupID = 20 kMDItemFSOwnerUserID = 501 kMDItemFSSize = 4264 kMDItemFSTypeCode = "" kMDItemKind = "OpenDocument Formula" kMDItemLogicalSize = 4264 kMDItemPhysicalSize = 8192