Bug 106830 - [implementation] Don't apply text file buffer operations on files with unkown content type
Summary: [implementation] Don't apply text file buffer operations on files with unkown...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.2 M2   Edit
Assignee: Platform-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-12 07:15 EDT by Martin Olsson CLA
Modified: 2005-09-16 07:04 EDT (History)
3 users (show)

See Also:


Attachments
weird error message given when JARs are corrupted (9.46 KB, image/x-png)
2005-08-12 07:16 EDT, Martin Olsson CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Olsson CLA 2005-08-12 07:15:19 EDT
I wasn't really sure if this was a JDT or Platform issue. Also choosing 
component "Text" was a pure guess. Please reassign if approriate.

---

The menu item "File :: Convert line delimiters to :: Unix" destroys JAR files. 
My project has a lib subdir with some external libs. Today I selected my 
project and used this menu item. I pressed ok directly to use the standard file 
selection. Now Eclipse started acting all weird and the workbench eventually 
crashed. When I tried to restart it it said workspace already in use. I checked 
tasklist, and killed of eclipse.exe (which was not showing in the bottom app 
bar just in tasklist). Tried again, same error; even with no eclipse.exe 
running it still said workspace in use. I rebooted and tried again. This time 
eclipse started but when I opened any file in my project the workbench crashes 
again. At this point it was saying stuff like this:

  http://mnemo.minimum.se/screens/eclipse_error.png

Now, at first I had no clue as to why Eclipse kept crashing but when I saw the 
error message about "invalid LOC header" in the JAR file I got suspicious. I 
downloaded the JAR files again and updated the contents of my project lib dir. 
Now it works again.

When I choose "File :: Convert file delimiter to :: Unix" again and checked 
what files are in fact selected by default and apparently (and also absurdly 
enough) JAR files are selected by default for CRLF to LF conversion. This is 
insane and needs to be fixed.
Comment 1 Martin Olsson CLA 2005-08-12 07:16:33 EDT
Created attachment 26040 [details]
weird error message given when JARs are corrupted
Comment 2 Martin Olsson CLA 2005-08-12 07:18:27 EDT
Also, maybe someone should review the JAR file handling in Eclipse. I mean, if 
a JAR file is corrupt I don't want this type of weird messages. I just want 
Eclipse to tell me in plain english that yadaBLAH.jar is corrupt. Certainly, 
crashing the entire workbench is bordering outrageous.
Comment 3 Dani Megert CLA 2005-08-12 08:39:31 EDT
The problem is as follows: for lots of files there's no content type. The
command currently checks all files that have content type TEXT or unknown. We
can invert the logic being more save but this means that many text files (e.g.
*.sql) which have no content type associated will not get converted.

I filed bug to request the addition of known content type.

>Also, maybe someone should review the JAR file handling in Eclipse. I mean, if 
>a JAR file is corrupt I don't want this type of weird messages.
Please file a separate bug report for this against Platform Runtime
Comment 4 Martin Olsson CLA 2005-08-12 11:24:42 EDT
I noticed later that this same function had also screwed up all my .png and .gif
icons. Does that mean these (very common) types (gif,png and JAR) does not have
a content type?
Comment 5 Martin Olsson CLA 2005-08-12 11:29:40 EDT
Ok, I've raised this bug in Platform :: Runtime too, here is the ref:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=106856
Comment 6 David Williams CLA 2005-08-12 17:34:15 EDT
I do believe its important to limit text operations only to TEXT content type
(or its "children") ... and, don't forget ... users CAN now add their own file
extensions to the TEXT content type, if we happen to omit one they use, but the
base does not use. And I believe that is the correct "assume no more than
needed" approach, and let users fill in details that meet their needs. I don't
know that much about SQL ... but suspect the base should not be the one to say
it is 'text'.

And hopefully if users are using SQL a lot, they will have a nice SQL plugin
that defines it as text. 

We (you, the platform) are already steatching it assuming manifest.mf is a
"Bundle Manifest File" :) ... it was, after all, a JAR manifest file first :(
... and then a war manifest file, and then ... :) 


BTW ... do you also exclude "system files" from text operations? (In the past, 
we've gotten some feed back we should never ever format them, for example, ... I
suspect similar for CRLF?
Comment 7 Rafael Chaves CLA 2005-08-15 13:36:18 EDT
Not wanting to divert, but re: comment 6, MANIFEST.MF will be only deemed as
Bundle manifest files if some OSGi specific headers are found, otherwise they
are recognized as plain JAR manifest files. David, if you see something
different, please open a PR against Platform/Runtime.
Comment 8 David Williams CLA 2005-08-15 13:59:34 EDT
Thanks Rafael, I took another look and see I was tricked by editor associations
... it is correctly identified as 'jar manifest file' ... and I've opened bug
107054 to track the PDE editor opening them. 
Comment 9 Dani Megert CLA 2005-09-16 07:04:39 EDT
Fixed in HEAD.