Menu
▾
▴
#967 FS Get File gives wrong output on Windows
When running this command through STAF, I get this result:
C:\Documents and Settings\Administrator>staf local fs get file C:\temp\wasinstall\media\db2-core\8.2\win32\gm\db2\ESE\setup.log
Response
--------
■-
Here is the query result on this file:
C:\Documents and Settings\Administrator>staf local fs query entry C:\temp\wasins
tall\media\db2-core\8.2\win32\gm\db2\ESE\setup.log
Response
--------
Name : C:\temp\wasinstall\media\db2-core\8.2\win32\gm\db2\ESE\setup
.log
Type : F
Upper 32-bit Size : 0
Lower 32-bit Size : 72416
Modified Date-Time: 20070620-13:01:47
The file setup.log was created by msiexec.exe's logging function after successfully installing DB2. This problem also seems to apply to all log files created by msiexec.exe.
After copying the file in binary to a Linux machine, running the same command generates the appropriate error message, where in Windows there was none:
C:\Documents and Settings\Administrator>staf local fs query entry C:\temp\wasins
tall\media\db2-core\8.2\win32\gm\db2\ESE\setup.log
Response
--------
Name : C:\temp\wasinstall\media\db2-core\8.2\win32\gm\db2\ESE\setup
.log
Type : F
Upper 32-bit Size : 0
Lower 32-bit Size : 72416
Modified Date-Time: 20070620-13:01:47
Log file created by msiexec.exe which gives the strange output
Logged In: YES
user_id=285070
Originator: YES
You can use notepad or wordpad to view the document. For example, it's contents begin with:
----------------------------------------------------------------
Setup Log File Opened... 2007-06-20 11:41:53
----------------------------------------------------------------
=== Logging started: 6/20/2007 11:41:55 ===
Action start 11:41:55: INSTALL.
Action start 11:41:55: AppSearch.
Action ended 11:41:55: AppSearch. Return value 1.
...
Logged In: YES
user_id=285070
Originator: YES
You can use notepad or wordpad to view the document. For example, it's contents begin with:
----------------------------------------------------------------
Setup Log File Opened... 2007-06-20 11:41:53
----------------------------------------------------------------
=== Logging started: 6/20/2007 11:41:55 ===
Action start 11:41:55: INSTALL.
Action start 11:41:55: AppSearch.
Action ended 11:41:55: AppSearch. Return value 1.
...
Logged In: YES
user_id=285070
Originator: YES
Note: This bug was actually found by Scott Collins when trying to use a FS GET FILE request to read data from the log files created by the DB2 installer msiexec.exe on Windows via a STAF Java service.
It appears that msiexec.exe is creating these files in a different codepage, ucs-2, than the codepage that STAF is using. STAF does not currently provided converters for usc-2 (aka UTF16_BigEndian or for UTF16_LittleEndian). Note that you wouldn't want to override the STAF codepage to usc-2 anyway as then it wouldn't be able to read other files that aren't in the ucs-2 codepage. In addition to STAF providing converters for usc-2 (which we already have features #888849 and #116558 open to use ICU so STAF can support more codepages), would also need feature #896050 "FS to support explicit codepage conversion" to allow you to specify the codepage to use on a FS GET request and would need another STAFConverter to convert from/to the specified codepage.
Note that the converting STAF to use ICU is a rather large feature and with the number of resources and number of open features we have, this won't be done in the immediate future.
Note that when using the STAF executable from a Windows command line to submit a FS GET FILE request on this file, it uses cout to output the file data and when it encounters hex 00, the C runtime thinks that indicates end of string which is why it only prints a couple of characters. When submitting a FS GET FILE request on this from a Java program, you actually get all of the data, but you also get a wierd block character between each character do to STAF not currently able to handle data in the ucs-2 codepage.
So, we recommend that in the meantime, use a FS COPY request to copy the file (if located on a remote machine) and then use Java APIs to read the file specifying it's codepage.