It's all about the answers!

Ask a question

MIME type is incorrect after using the ClearCase synchronizer


Stephane Couillaud (15632545) | asked Feb 04 '15, 7:07 p.m.
edited Feb 04 '15, 7:17 p.m.
 We are experiencing some issues migrating source code from ClearCase to RTC using the ClearCase synchronizer where the resulting MIME type for imported java files in RTC is inconsistent.  Perhaps someone could shade some light for us.  I will take for example two typical Java files we have in ClearCase (i.e. Aligner.java & Aligner9300.java) which we just migrated.  If we look at the properties of both files in ClearCase we get the following:

     

If we look at the ClearCase element type properties in type manager for java_source we get the following:

    

When we migrate both files using the ClearCase synchronizer we get different MIME types for both files. 

File properties for file Aligner.java


File properties for file Aligner9300.java

One file has MIME type application/unknown while the other has text/plain.  Is there any reason why these two files should end up with different MIME types after being imported together at the same time?  What are the implications if now some or my java files are set to application/unknown?

For background here are some of the settings used on the ClearCase synchronizer and project area:

We followed the instructions from this section of the 4.0.6 documentation: Setting line delimiter handling where you need to modify the process template of the project area.  Here’s the before and after XML code.
 
Before:
<configuration-data id="com.ibm.team.scm.service.projectLineDelimiterHandling">
</configuration-data>
 
After:
                  <configuration-data id="com.ibm.team.scm.service.projectLineDelimiterHandling"><projectLineDelimiterHandling projectLineDelimiterHandlingValue="NONE"></projectLineDelimiterHandling>
                  </configuration-data>
 
Furthermore, from the ClearCase Synchronized Streams view, we  changed some of the ClearCase Provider Properties of the stream from
 

1.       LINE_DELIMITER                               = LF
2.       LINE_DELIMITER_WORKSPACE     = PLATFORM

 
to
 

1.       LINE_DELIMITER                               = UNSPECIFIED
2.       LINE_DELIMITER_WORKSPACE     = UNSPECIFIED

 
The above settings are based on this section of the 4.0.6 documentation: Specifying line termination characters for text files

One answer



permanent link
Geoffrey Clemm (30.1k33035) | answered Feb 06 '15, 1:56 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The only explanation I could imagine would be if these two files were initially imported during different import runs, with different ClearCase Provider properties set.   Is there any possibility that is what happened?   (Note that the first import of a given element determines those properties ... subsequent re-imports would not change them).

Comments
Stephane Couillaud commented Feb 06 '15, 2:26 p.m. | edited Feb 06 '15, 7:19 p.m.

 That's the mystery as both files were imported on the same run and ended up with different MIME type and encoding. For those file that have the incorrect MIME Type (i.e. application/unknown).  We will try and reproduce. In the mean time, we are able to open those files and work with them in the Java perspective.  We can also open them in all editors, do compares, etc..  The only issue we encounter is when we right click on a component, select "Show>Repository Files" and try to open one of the files with the incorrect MIME type.  What we get is the following screenshot:



If we click on "Set Encoding..."  and click OK on the pop up window (i.e we do not change anything and accept what's already set)


Then we are able to see the code.   Is this a bug or is this the expected behavior?  If we leave the MIME type and encoding as is are we to expect any issues?

BTW the same goes from a browser where it will not display the text file unless we click on the "show anyway" link below:



Geoffrey Clemm commented Feb 06 '15, 11:39 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Probably best to get Rational Support involved (if you haven't already done so).  Were you able to recreate this problem (perhaps creating a new CC element that is a copy of Algner.java, and importing that).  One detail: is this a 2-way sync stream, or an import-only synch stream?  I assume you have investigated whether Algner.java has any unusual characteristics when accessed from ClearCase?


Stephane Couillaud commented Feb 09 '15, 2:21 p.m.

 Apologies for responding late as I never got alerted despite being subscribed to this post.  Yes we do have a PMR but responses have been slow.  We did do as you suggested by creating a new VOB that contains those CC elements we're having issues with.  The import-only (not two way) was successful and the MIME type was set text/plain as expected.  There are no unusual characteristics for that Aligner.java file compared to those that imported correctly.


I guess our issue now is that all those files already exist in the component that we're importing to.  Are there any other alternatives for us to reimport from scratch in this component other than correcting on the RTC side by the use of scripts and such?  Creating a new component is not an option as we have about a year of development in it already. 


Geoffrey Clemm commented Feb 10 '15, 1:11 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I would think the best approach would be to use a shell script and the scm command line tool to locate and update files with the wrong MIME type.   Since you cannot reproduce the problem, that will of course make it harder for Support to track down.  Perhaps once you identify all the files with the wrong MIME type, you might notice some kind of pattern?

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.