Community
Participate
Working Groups
The Buckminster headless configuration was designed with two major objectives in mind: 1. To be as small as possible (we'd like to spawn it with Java Web Start) 2. To be platform agnostic We now have a product that runs very well and meets those objectives. Download once and run everywhere. This enables us to do distributed builds etc. using the same binaries in a server farm containing many different platforms. We have one aesthetic problem however. When used on a windows platform, it spits out the following annoying message: "Could not load library: localfile_1_0_0.dll. This library provides platform-specific optimizations for certain file system operations. This library is not present on all platforms, so this may not be an error. The resources plug-in will safely fall back to using java.io.File functionality." Is there anyway to turn this off? The fact that the localfile_1_0_0.dll is missing is in our case very intentional. It is platform specific and doesn't provide any functionality that we need. Kind Regards, Thomas Hallgren
This problem is apparent in both 3.2.x and 3.3
This is just information not a warning. However because the native filesystem fragment is optional, we shouldn't log it each time when the native fragment doesn't exist. I think that we could add an extra option org.eclipse.core.filesystem/native in the .options file which would be turned on by default.
I think we need to show this by default, but having some way to turn it off would be fine (e.g., a system property).
Thomas, as I understand what you want to avoid is displaying the message in Log View, right? Or you consume the the log file directly and don't want the entry to be written at all? This bug looks to me as a more general problem. Plugin providers are free to write any information to the log they consider appropriate. And introducing a property per entry is not the right way. The best way would be to move StatusManager to core plugins and give an ability to add a custom status handler. The handler could decide then which entries to ignore. Other solution is to ask the UI team to add API to set filters on Log View. As far as I debugged the code it seems like there is no such ability at the moment.
BTW moving StatusManager to core is tracked by bug 193110.
Although I see that some improvements could be made to the logger, I don't think this problem is entirely generic. From my point of view, this is more related to headless execution versus running in the IDE. When doing the former, there's no need for the localfile_1_0_0.dll since the services that it provides are intended for automatic updates etc. of the workspace. I would be happy if this particular log entry was disabled when running headlessly.
(In reply to comment #6) > there's no > need for the localfile_1_0_0.dll since the services that it provides are > intended for automatic updates etc. of the workspace. The workspace can pick up changes made to the underlying file system without any native support. However there is native support for Windows which performs better. It is provided by org.eclipse.core.resources.win32.x fragments and win32refresh.dll. Lack of win32refresh doesn't affect Eclipse capability. localfile_1_0_0 is about something else. It adds platform-specific optimization for file operations. It also allows for working with file properties which are not reachable using java.io. Without this support, users are limited to java.io. That's why they are informed about it. Anyway both libraries are useful in headless applications.
Marking as WONTFIX for the reasons mentioned in comment 4 and comment 7. Lack of the library not only introduces performance impact but also limits resources capability. Take for example when copying files without native support file properties are not copied to the new file. That's why users are informed. A workaround this problem will be available along with the fix for bug 193110.
