Community
Participate
Working Groups
Build ID: eclipse-SDK-3.2.1-win32.zip Steps To Reproduce: 1. Download eclipse-SDK-3.2.1-win32.zip 2. Unzip You are prompted to give a password for several files, including "autoRefreshCallbacks" More information:
I'm assuming you're using Vista? This sounds like a Vista "feature": http://blogs.msdn.com/robcaron/archive/2006/09/14/755306.aspx
No, Windows XP. I first tried to copy the files by dragging out of Windows "compressed folder" browsing feature, but it just got half way and failed. When I explicitly extracted it, it got stuck on a few files, prompting for a password. I skipped these files and it all seemed to work... (In reply to comment #1) > I'm assuming you're using Vista? This sounds like a Vista "feature": > > http://blogs.msdn.com/robcaron/archive/2006/09/14/755306.aspx >
The problem on Vista is with extracting to a deep folder. Can you try extracting to something like c:\tmp to see if that is the cause of the problem in this case? The zips on eclipse.org are certainly not password-protected.
Not an Eclipse bug.
*** Bug 167550 has been marked as a duplicate of this bug. ***
While it is technically correct that the root problem is in windows code, the attitude here is a bit cavalier for my taste. Given the large number of questions this problem generates on the newsgroups, I'd say it is in Elcipse's best interest to try to find a way to alleviate Eclipse bumping into this Microsoft bug. Can we re-open this for discussion? Is there really nothing that can be done to avoid the windoze problem. I'm sure Eclipse loses some new users before they even get started because of this. In any case, the "Works For Me" resolution seems inappropriate since this is reproducible by a lot of people.
We get lots of Unzip-related e-mails in the webmaster@eclipse.org inbox also. This problem is causing a lot of grief for a lot of people, including many potential Eclipse newcomers, and I'd like to echo the contents of comment 6. Bug 30859 is also somewhat related, where it is requested that a formal installer be included with Eclipse.
I'm not sure if WORKSFORME or WONTFIX is better than the other but both seems to be appropriate. This path limitation on Windows is a long known issue and there doesn't seem to be any other valid workaround than using a shorter path. I don't think that Microsoft will ever address this limitation just because of Eclipse. Eclipse could only implement hacks (eg. rename files) but that would only work for a small percentage of users till the limitation is hitagain and is not possible for all files. FYI, bug 169776 requests to add a prominent note on the Eclipse download side about this limitation. I think that's a good thing to do meanwhile.
Renaming files isn't the solution. What you would need to is to re-write all our file handling code to break long paths up into chuncks that Windows could deal with and convert each absolute operation into multiple relative directory operations (to move to the desired destination directory) and then do the result on the (relative) filename. I have written code to do this before, and I can tell you that it tends to be both fragile and inefficient (and not just because I'm a crappy coder ;-) ). Even if we were willing to live with that, it doesn't change the fact that any code that directly uses java.io.File and friends would still exhibit the problem. If the community believes this problem needs to be solved, then they should be talking to the VM vendors to get them to fix Java file handling on Windows.
Wow! Am I behind the times, or what. I just checked with John Arthorne: First off, modern versions of Windows *do* support long file names if you prefix the path string appropriately to warn it. Secondly, Java 5 uses this support. Thirdly, All our natives have been fixed to do this as well, as of M4. Can someone try one of the failing cases on a Java 5 VM + M4 and see if it works now?
(Yes, you would have unzip using "jar xvf..." <g>)
(In reply to comment #9) > Renaming files isn't the solution. What you would need to is to re-write all > our file handling code to break long paths up into chuncks that Windows could > deal with and convert each absolute operation into multiple relative directory > operations (to move to the desired destination directory) and then do the > result on the (relative) filename. [snip] I think you are confusing this issue with another. What this bug is about is the fact that Windows XP can not unzip the Eclipse downloads (the "install" packages) when the place where the user is trying to install is a deep location on the file system. It has nothing to do with the JVM or Eclipse code.
Eclipse as of 3.3 M4 does support long paths in the user's workspace (bug 30995), but this problem is encountered by unzip utility before Eclipse even starts. The only workaround I can think of in this case is to shorten the names of the files and directories in the Eclipse install tree. It's a total hack, but I will rename the "autoRefreshCallbacks" directory. That is the long path in the install, so renaming it will allow the user a few more characters in the install base directory. The problem is also exacerbated by the long auto-generated paths of feature directories.
Changing to a more appropriate resolution. This is reproducible, but it's not an Eclipse bug.
(In reply to comment #13) > Eclipse as of 3.3 M4 does support long paths in the user's workspace (bug > 30995), but this problem is encountered by unzip utility before Eclipse even > starts. The only workaround I can think of in this case is to shorten the names > of the files and directories in the Eclipse install tree. It's a total hack, > but I will rename the "autoRefreshCallbacks" directory. That is the long path > in the install, so renaming it will allow the user a few more characters in the > install base directory. The problem is also exacerbated by the long > auto-generated paths of feature directories. > That sounds like a good start. What about using a self-extracting file instead of a plain ZIP file? That would avoid the Windows XP/vista ZIP file "feature" altogether. Is it feasible for someone to explore WinZip Self-Extractor or similar tools in that arena? I'd be surprised if there is not something open-source.
(In reply to comment #14) > Changing to a more appropriate resolution. This is reproducible, but it's not > an Eclipse bug. > While I appreciate that there is some attention being paid, I'll refer again to Comment 6 and Comment 7 where you have both the user community and the Eclipse webmaster stating that this is a widespread problem. I don't think it is relevant that there is no bug in Eclipse code - the issue still needs to be addressed. The perception is that the Eclipse downloads are broken; that perception should be the focus. Believe me, there is no love lost between myself and Micro$oft or Windoze; but I don't find it acceptable to just point at them and say "its their problem." I can't believe all the brilliant people who have built Eclipse can't come up with a way to avoid the unzip problem. Shortening some of the longest names is, as I said, a start; but is there nobody else within the Eclipse dev team who considers this as a bad PR situation? Is there any indication as to why Bug 30859 (or something simpler, such as a self-extracting file) has not gained any traction?
(In reply to comment #8) > FYI, bug 169776 requests to add a prominent note on the Eclipse download side > about this limitation. I think that's a good thing to do meanwhile. This has been added, but you'll only see the message if you're using Windows.
> Is it feasible for someone to explore WinZip Self-Extractor or similar tools in that arena? It's certainly feasible. For anyone interested in exploring this, I recommend "How to write an Eclipse installer" in the Eclipse help.
*** Bug 280762 has been marked as a duplicate of this bug. ***
So this is an ancient discussion thread about a bug I have never experienced until today.. I have used Eclipse for years, setting it up several times on xp vista and 7, never having this problem until now. 3rd party zip tools suck so, this HAS to work with windows. And it has, so I don't know what's different right now. I'd rather write my code in notepad than deal with it. This issue is NOT resolved.
I'm very put off by John Arthorne and Michael Spector.. You guys have been dodging this issue for 6 years now.. If you know that the problem is because your file names are too long then for cryin out loud, quit blaming windows and design your shit right.. I am officially wiping my ass with Eclipse and I will be just fine without it.. So I guess if you want 2 keep blaming other people and being sloppy, lazy coders, then F and U.. Adios..
Just to record here for reference, there has been improvement in this area. When this bug was reported in 3.2, the longest path in the Eclipse SDK was 198 characters. In Eclipse SDK 4.2, the longest path is 155 characters. This means in order to get the failure, you need to unzip into a directory that already has 100 characters in the path. I'm sure there is still more room for improvement but shortening paths and dealing with the corresponding compatibility/migration can be quite complex. In the meantime there are workarounds such as using a shorter install path, or extract with 7Zip, WinZip, etc. It can even be extracted directly with java on the command line: C:\somereallylongpath> jar xf eclipse-SDK-4.2-win32-x86_64.zip
I realize that making changes 2 an application can be complex, but what put me off was Michael Spectors comment in another related thread that they weren't going fix something just because it doesn't work with windows.. The problem is, if you want 2 label your software as a windows application, well, you gotta develop it to suit the platform.. I appreciate that final tidbit.. I will try unzipping using java at the command line.. That's enough 2 get me 2 open my mind again.. Thanx
Spamming Eclipse.org is a waste of time
Bugzilla is not a place for product placement though.
Using Windows 8.1 and just downloaded Mars; Eclipse has to run in a self-contained folder in an NTFS LAN file server. Doesn't extract because of the massive amounts of nesting as previously mentioned in this bug's history. My organisation therefore can't use Eclipse, because although it works, I'm not unzipping an individual copy of it on my local machine to keep the file path short. I'm not wasting time getting 3rd party tools to deal with extended file paths: Eclipse either works with Windows or it doesn't. I can't unzip it: so it doesn't work. Time to find a new IDE.
Jim, Thank you for your feedback. Have you tried the new installer? It should just work out of the box: https://www.eclipse.org/downloads/installer.php Please give it a try and report back on your impressions.
Map a drive letter to your long root path, like subst R: D:\Long\Path\That\Serves\As\Eclipse\Root Then reference the Eclipse zip file as R:\eclipse-whatever.zip See http://serverfault.com/a/654756
(In reply to Denis Roy from comment #27) > Jim, > > Thank you for your feedback. Have you tried the new installer? It should > just work out of the box: > > https://www.eclipse.org/downloads/installer.php > > Please give it a try and report back on your impressions. Installer works without problems - might I suggest clearer notification for Windows users on the site when going to download? Thanks for the tip.
I'll push to make the Installer the default for Windows. The installer is still kinda "beta" but on Windows it seems to provide a better out-of-the-box experience for users. Thanks again for taking the time to provide feedback, even if it may not be what we want to hear.
I was going to let the previous one slide, but now you annoying spammers have given me an incentive to Search & Replace all occurrences of that three-word product you keep placing in here. Bye Bye.
Long Path Tool helped me in this situation.
