United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8021943 : FileDialog getFile returns corrupted string after previous setFile

Details
Type:
Bug
Submit Date:
2013-07-29
Status:
Resolved
Updated Date:
2013-10-28
Project Name:
JDK
Resolved Date:
2013-09-04
Component:
client-libs
OS:
windows_7
Sub-Component:
java.awt
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
7u5,7u15,7u21,7u25,7u40
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version  " 1.7.0_25 " 
Java(TM) SE Runtime Environment (build 1.7.0_25-b17)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
When using FileDialog#setFile() with a long file name and then selecting a shorter file name in the dialog box subsequent #getFile() call returns a corrupted String consisting of the selected file plus parts of the string submitted to setFile.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
see: http://stackoverflow.com/questions/14972664/java-getfile-returns-incorrect-filename-after-using-setfile

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Filename selected in FileDialog dialog
ACTUAL -
Corrupted string consisting of selected file name of the string submitted to setFile

REPRODUCIBILITY :
This bug can be reproduced always.
                                    

Comments
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/ba711056009f
User:  lana
Date:  2013-10-01 17:37:37 +0000

                                     
2013-10-01
Removed the regression label since this is not a regression in JDK 8.
                                     
2013-09-06
Still pending Introduced In Release
                                     
2013-09-04
it works fine up to 6u35 but having problem since 7u5, 7u15 and 7u25. CAP member requested the same fix back port to 7u releases because this will cause issues with many of our customers.
                                     
2013-09-04
URL:   http://hg.openjdk.java.net/jdk8/awt/jdk/rev/ba711056009f
User:  pchelko
Date:  2013-09-04 10:33:31 +0000

                                     
2013-09-04
lpstrFile should be treated as double NULL terminated (DNT) string only when OFN_ALLOWMULTISELECT flag is set.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646839%28v=vs.85%29.aspx
> If the OFN_ALLOWMULTISELECT flag is set and the user selects multiple files, the buffer contains the current directory followed by the file names of the selected files. For Explorer-style dialog boxes, the directory and file name strings are NULL separated, with an extra NULL character after the last file name. 
Currently we check length of a lpstrFile with GetBufferLength() which treats \0\0 as an end of a string.
It works nice, unless we call setFile() with a filename longer than a path of a saved file (in single-select mode).
In single-select mode lpstrFile string ends with single \0, and GetBufferLength() fails to find correct length and we pass \0-separated buffer to
WFileDialogPeer.handleSelected()  which will be treated as multi-select mode.


                                     
2013-09-04
Same issue reported by a CAP member -

the getFile() and getDirectory() methods of java.awt.FileDialog (in SAVE mode) are behaving differently between the 2 versions when you use setFile() before the dialog is displayed.

In JRE 6, when you open the dialog and type a name in the field. getDirectory() returned the directory selected, and getFile() returned the text in the field.
 
Now getDirectory() returns the full path, and getFile() returns the original file name set with setFile() but it is truncated by the number of characters returned by getDirectory().

This link indicates the issue -

http://stackoverflow.com/questions/14972664/java-getfile-returns-incorrect-filename-after-using-setfile

Example: when create the dialog, make a call to setFile() with the parameter ???along_filename.epf???, for example, before displaying the dialog. display the dialog, the directory is ???C:\??? and the field correctly shows ???along_filename.epf???. If delete ???along_filename.epf???, type ???test???, and click Save. expect that getDirectory() will return ???C:\??? and getFile() will return ???test??? as it does in JRE 6.

Instead though, getDirectory() returns ???C:\test??? and geFile() returns ???ilename.epf???.

                                     
2013-09-03
pending evaluation, what is introduced in release?
                                     
2013-07-31
wrong info added here (sorry for any confusion
                                     
2013-07-31
Need SQE-OK before this can be approved
                                     
2013-07-31
This P3 isn't a stopper / blocker. Requested to defer.
                                     
2013-07-31



Hardware and Software, Engineered to Work Together