JDK-8080369 : (fs) Files.probeContentType returns null on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 8u40,8u60
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: windows_8
  • CPU: x86
  • Submitted: 2015-04-16
  • Updated: 2015-06-27
  • Resolved: 2015-06-27
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorResolved
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
1.8.0_45

ADDITIONAL OS VERSION INFORMATION :
Window 8.1 32 bits

EXTRA RELEVANT SYSTEM CONFIGURATION :
Files.probeContentType(file.toPath()) returns null for all tested files: txt, pdf and .ini.



A DESCRIPTION OF THE PROBLEM :
This doesn't happen on Windows 7 64 bits using jdk 1.8.0_45. So it must be a bug in the jdk 1.8.0_45 for 32 bits.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Testiing code:

// http://www.ibm.com/developerworks/library/j-nativememory-linux/j-nativememory-linux-pdf.pdf

FIle file = new File(D:\\j-nativememory-linux/j-nativememory-linux-pdf.pdf);

      if (file.isFile())
      {
           String s = Files.probeContentType(file.toPath());
           // s is always null on Win8 32 bits, this works on Win7 64 bits
      }

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Files.probeContentType must return "application/pdf" for pdf files.
ACTUAL -
Files.probeContentType returns null for pdf files.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Throws Java.NullPointerException whe tried to do:

 Files.probeContentType(file.toPath()).equals("application/pdf");

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
// http://www.ibm.com/developerworks/library/j-nativememory-linux/j-nativememory-linux-pdf.pdf

FIle file = new File(D:\\j-nativememory-linux/j-nativememory-linux-pdf.pdf);

      if (file.isFile())
      {
           String s = Files.probeContentType(file.toPath());
           // s is always null on Win8 32 bits, this works on Win7 64 bits
      }
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
reading pdf's header


Comments
As noted, the problem occurred because of a key missing from the Windows registry so it is being resolved as not representing a problem in the probeContentType() implementation per se on Windows.
27-06-2015

Barring objections to the contrary I plan to resolve this as "Not an Issue" with respect to the Windows behavior. The behavior on Mac OS X will be addressed under JDK-8129632.
26-06-2015

Sent an email to the submitter with above comments, requesting their response.
16-06-2015

I reproduced this failure on a Windows 7 64-bit machine, which is the environment in which the submitter claimed it worked, and then checked the registry and found that it was due to a the "Content Type" sub-key of the ".pdf" key being absent. I do not have any Adobe software installed which one might infer explains the sub-key's absence.
15-06-2015

On Mac OS X, the MIME type can be retrieved from the file extension using Uniform Type Identifiers: https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html Specifically this sequence of code: const char *fileExtension; // NULL-terminated C-string containing the file extension CFStringRef extension = CFStringCreateWithCString (NULL, fileExtension, kCFStringEncodingUTF8); CFStringRef uti = UTTypeCreatePreferredIdentifierForTag (kUTTagClassFilenameExtension, extension, NULL); CFStringRef mimeType = UTTypeCopyPreferredTagWithClass (uti, kUTTagClassMIMEType); A C-string may be extracted from the CoreFoundation string "mimeType" for conversion to a Java string. The foregoing code was verified using the file extensions in this set {"doc", "odf", "pdf", "png"}. I don't know as yet whether there is an API for extracting the MIME type in the event there is no file extension, e.g., from the magic bytes in the file header.
15-06-2015

It looks like the JDK already has code to use libmagic, but apparently OS X doesn't have the library available. Perhaps the 'file' tool statically linked it or something. If a version of libmagic is bundled with the JRE then the existing magic database on OS X can be used.
15-06-2015

Consider using https://github.com/j256/simplemagic
13-06-2015

Relying on a file that is known to be absent from the system is clearly not a reasonable implementation of this API. You might as well just say that the default implementation doesn't work on OS X. I know I can run "file --mime-type whatever_file_here" at a command prompt and get the MIME type. So worst case java could do the same. I don't recommend actually running the 'file' program though. It would make more sense to implement a Java version of it directly using the same information that the 'file' program does. See the man page for more information. In any case the data at /usr/share/file/magic shouldn't be hard to use.
12-06-2015

On OS X the implementation relies soley on ~/.mime-types. Is there any source of MIME types on OS X that can be used? As always with the Files.probeContentType implementation, it's possible for frameworks and applications to configure their own FileTypeDetector.
12-06-2015

This issue exists also for OS X. Tested with 8u60 b19. All files return null. There is an issue JDK-8008345 that indicates that a file ~/.mime-types is needed. Since that file doesn't exist, the current implementation on OS X cannot be considered working or reasonable.
12-06-2015

Windows maintains its MIME mapping tables in the Windows registry.
14-05-2015