Bug 203357 - XML and XMI files always transfer binary
Summary: XML and XMI files always transfer binary
Status: RESOLVED DUPLICATE of bug 203114
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: All All
: P3 normal with 1 vote (vote)
Target Milestone: 3.0 M4   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: investigate
Depends on: 199773
Blocks: 203114
  Show dependency tree
 
Reported: 2007-09-13 16:20 EDT by Martin Oberhuber CLA
Modified: 2007-11-14 14:12 EST (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-09-13 16:20:57 EDT 
+++ This bug was initially created as a clone of Bug #199773 +++

FileServiceSubSystem always transfers *.xml and *.xmi files in binary mode, because it thinks that the encoding is typically embedded in those files.

But this logic is not quite correct. User Preference from FileTransferModeRegistry should be used, if user explicitly asks for ASCII transfer; Source and target encodings should just be the same in case of such ASCII transfer.

This issue needs more investigation, for details see bug #199773.
Note that this may be a regression compared to RSE 1.0.1, in terms of FTP.
Comment 1 Martin Oberhuber CLA 2007-09-19 10:23:46 EDT 
We agree that there should not be any built in default-defaults. Current behavior should be explicitly visible (and user-changeable) in the prefs.

See also bug 203114 for improving the Prefs UI.
Comment 2 Jeff Maxwell CLA 2007-09-24 14:27:08 EDT 
This is a blocker for users of the Z/OS platform.
The user preference should override the isXML logic.
Comment 3 David McKnight CLA 2007-11-14 14:12:22 EST 
I've changed things (in bug 203114) so that XML is never treated specially.  Instead we default to binary for XML but the user can change that in the preferences.

*** This bug has been marked as a duplicate of bug 203114 ***