JDK-8021943 : FileDialog getFile returns corrupted string after previous setFile
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u5,7u15,7u21,7u25,7u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_7
  • Submitted: 2013-07-29
  • Updated: 2014-02-12
  • Resolved: 2013-09-04
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.
JDK 7 JDK 8
7u60Fixed 8 b110Fixed
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
Removed the regression label since this is not a regression in JDK 8.
06-09-2013
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.
04-09-2013
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.
04-09-2013
Still pending Introduced In Release
04-09-2013
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���.
03-09-2013
wrong info added here (sorry for any confusion
01-08-2013
Need SQE-OK before this can be approved
31-07-2013
This P3 isn't a stopper / blocker. Requested to defer.
31-07-2013
pending evaluation, what is introduced in release?
31-07-2013