JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

[Roger Riggs]

Hi Brian,

Looks good

Except for a typo in WinNTFileSystem_md.c:24  "compnent"

Regards, Roger


On 12/19/2016 3:54 PM, Brian Burkhalter wrote:
> Hi Roger,
>
> Thanks for your suggestions. An updated version of the patch is here:
>
> http://cr.openjdk.java.net/~bpb/8148023/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ebpb/8148023/webrev.01/>
>
> On Dec 19, 2016, at 11:04 AM, Roger Riggs <Roger.Riggs at Oracle.com 
> <mailto:Roger.Riggs at Oracle.com>> wrote:
>
>> File.java:
>>
>> - 1906: shortenSubName might reasonably return the new length without
>>   creating the intermediate string and save on the allocation.
>
> So changed.
>
>> - generateFile() line 1922 + --  I assume this slow path is 
>> infrequently used.
>>  Otherwise, the computations involving excess could be done 
>> arithmetically without actually creating the string
>>  and only create the name when the final length(s) are decided.
>
> Modified.
>
>> - line 1952:  appending the generated name to the exception is ok but 
>> it should omit the directory name;
>>   its not salient to the error and might expose a sensitive directory 
>> name.
>
> Updated.
>
>> FileSystem.java
>> - getNameMax;  the length could reasonably be just an int.  Long 
>> seems a bit excessive
>>   and raises suspicion that something clever is going on when its 
>> just a normal value.
>>  (Though I see the native code uses jlong)
>
> Changed to an int except for the native Unix call. The invoking Java 
> code clamps a highly unlikely out-of-range long to Integer.MAX_VALUE.
>
> Thanks,
>
> Brian