Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1.Search in /var 2.See that the search gets stuck on files like /var/run/xdmctl-:0 More information: It would seem useful to perhaps filter out special filesystem files such as devices, fifos, etc so these aren't attempted to be searched in. Alternatively the hang could be fixed with a timeout that would abort the searching of a file after a period of time so the search could resume.
How did you search in '/var'? Text search is designed to search in the workspace. If you added '/var' as linked folder also other applications will run in problems when trying to open these special files.
I need more information here, see comment 1. Setting to INVALID. Reopen if you have more information
Sorry about that, I completely didn't see your first comment. In this case yes, I had a directory that was a symlink to a directory in /var that contained fifos and that was causing the hang during the directory recursion. In my case it was a symlink from a directory for apache's configuration called 'run' that was symlinked to /var/run. The symlink is in the workspace but the directory it links to is not. I agree that it isn't a wise thing to symlink to a directory with special files in it but it isn't easy to fix since the config files are next to the symlinks and its useful to keep the whole bundle in svn along side of the php files etc. It would be great to just have eclipse avoid opening fifos and maybe other kinds of special files if it isn't a big performance issue and isn't difficult to implement. If its too corner case that's ok too. I'm a fellow opensource developer and I know there are only so many hours in the day.
Moving to Platform/Resources. Special files like fifos should be filtered and not be visible as IResource.
(In reply to comment #4) > Moving to Platform/Resources. Special files like fifos should be filtered and > not be visible as IResource. > I can assume that the hang occurs because the search tries to read the content. Why should we filter out these special files? I think that we should not try to read their contents during the text search, but they should be still visible.
First, we would need to be able to recognize such resources. Then, all clients would have to add tests to avoid reading the contents. IMO it's best solved at the Platform/Resources level: Either filter them or let file.getContents() return an empty stream.
I found bug 177527 and bug 116728. I remember that CDT issue was solved during 3.4. The search problem was already mentioned in bug 177527, comment 0, but was lost during the discussion. (In reply to comment #6) > IMO it's best solved at the Platform/Resources level: Either filter them or let > file.getContents() return an empty stream. So what about the clients expecting to see those files in the workspace? If we return an empty stream, it can make some people confused. Let's say that we have a pipe and a job reading its content. It would be expected that this job waits till one starts to write to the pipe. We could think about a flag indicating that the file is a pipe. It would be a similar story to symbolic links one. I will use this bug report to discuss the general solution for pipes.
> So what about the clients expecting to see those files in the workspace? Do we know of client who do that? Wouldn't this be a Linux/Unix specific thing that doesn't exist cross platform? I guess if they want to access such pipes, they can also use normal java.io.File access to do that. I think not only text search has a problem here. Probably all features that try to open such a file (Editor, Refresh action, ...).
(In reply to comment #8) > > So what about the clients expecting to see those files in the workspace? > Do we know of client who do that? Wouldn't this be a Linux/Unix specific thing > that doesn't exist cross platform? MacOS too.
A user here has had this problem as well. There are other instances where the workspace contains special files -- e.g. a developer using CDT with a kernel build tree (which generates magic device files as part of the build). It's worth noting that the CDT binary parser used to also exhibit this problem -- see bug149428. Now it performs this check: Util.isNonZeroLengthFile(locationURI) before attempting to read from the file. It must be a bug that the text search hangs on these special files -- it's even worse as the user can't cancel the search.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
