[9] RFC on 8080369: (fs) Files.probeContentType returns null

[Brian Burkhalter]

On Jun 23, 2015, at 2:26 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>> 1) Should the old and new approaches be chained in Mac OSXFileSystemProvider.getFileTypeDetector() or should the UTI-based implementation simply replace the old implementation? I don’t myself see any reason to keep the old version as it is essentially non-functional.
> I think MimeTypesFileTypeDetector should be the first in the chain as that makes it easy to override. This detector is more useful on Linux and Solaris because it is setup to search /etc/mime.types too.

Good point.

> On these platforms then I think it's time to look at dropping the GNOME implementation.
> 
>> 
>> 2) The file extension is passed to and returned from the native layer as a Java string. Might it be better to use some other approach, for example using a NativeBuffer as in the Linux MagicFileTypeDetector?
> For OS X then I think your approach is okay.
> 
>> 
>> Note that the issue was originally filed against the Windows implementation. Testing showed that the failure was likely due to an entry missing from the Windows registry. The original submitter was queried to verify whether the same situation obtained on the machine where they observed the problem. In the absence of a contradictory response from them, the Windows portion of the issue is evaluated as “Not an Issue.”
>> 
> If you want to create a new issue for the OS X issue then that should be fine

I could file two other, linked issues: one for OS X, and another for removing the GNOME implementation.

> (I think what happened here is someone jumped on the bug without realizing it was a Windows issue).

I completely agree.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20150623/fbe24630/attachment-0001.html>