Doesn't recognize ODF files without file extension #34

Activity

1. TomTasche

   self-assigned this

   on Apr 2, 2020
2. TomTasche commented on Apr 2, 2020

   

   TomTasche

   on Apr 2, 2020

   MemberAuthor

   More actions

   @Metaxa007 says this is not reproducible. Need to test again
3. TomTasche commented on Apr 2, 2020

   

   TomTasche

   on Apr 2, 2020

   MemberAuthor

   More actions

   I can still reproduce this by uploading an odt-file without file extension via the iCloud web interface: https://www.icloud.com/iclouddrive/
4. TomTasche

   assigned

   Metaxa007

   and unassigned

   TomTasche

   on Apr 2, 2020
5. andiwand commented on Aug 21, 2026

   

   andiwand

   on Aug 21, 2026

   Member

   More actions

   Not an odrcore problem. open_strategy::list_file_types works from the magic bytes and then probes the zip for an ODF manifest — no extension is read anywhere in that path, and CoreWrapper calls exactly it. An extensionless ODT opens fine once the app can reach the file.

   What blocks it is one system rule. Copying test.odt to a name with no extension and asking UniformTypeIdentifiers:

   file	resolved type	conforms to zip / content / composite
   noext	public.data, not dynamic	false / false / false
   withext.odt	org.oasis-open.opendocument.text	false / true / false

   No extension means public.data exactly, conforming to nothing else, and UIDocumentBrowserViewController greys out whatever does not conform to a type in CFBundleDocumentTypes. iOS resolves the type from the extension and the file provider's metadata, never from the content, so no declaration short of public.data itself reaches that file.

   Three ways out:

   1. Claim public.data. One line in both plists and it is ungreyed. The same key drives Open-With, so the app becomes an offered opener for every file on the device — Please let users choose which file types OpenDocument Reader handles #150 asks for the opposite. Wrong trade.
   2. Claim public.data with LSHandlerRank: None. None means the app never opens the type, so in principle the browser's filter still sees the claim while Open-With does not offer it. Undocumented for the document browser and it may drop the type outright. Cheap to settle by running it: is the file ungreyed, and does the app show up for an mp3. Worth testing before anything else — if it holds it is a one-line fix at no cost.
   3. An explicit way in. A button in additionalLeadingNavigationBarButtonItems — the trailing side carries Privacy — presenting a UIDocumentPickerViewController(forOpeningContentTypes: [.item]), whose list is not filtered by what the app declares. The picked URL goes to presentDocument(at:) unchanged and odrcore identifies it. Needs startAccessingSecurityScopedResource(), which nothing does today because browser-handed URLs do not need it. It does not ungrey the file in the list, so the reader has to find the button, and the picker shows everything — an mp3 picked there gets the cannot-open message.

   Suggested order: test 2, fall back to 3.