Community
Participate
Working Groups
Status WARNING: com.ibm.team.filesystem.client code=0 Problem detected: your filesystem supports symlinks but you are missing the Eclipse native support for them null. I am using Rational Team Concert 2.0.0.2
See https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/114325
Support here means that LocalFile.fetchInfo() should be able to detect symbolic links and return the target just like it does on UNIX.
Created attachment 168652 [details] proposed patch For what it's worth here's a patch on top of 3.5.2 that works for me.
Dmitry - Will this patch work with RTC 2.0.0.2 , since it has Eclipse 3.4.2 ?
I think so, the only difference between 3.4.2 and 3.5.2 is the copyright notice.
Created attachment 169094 [details] Patch_v01 Thank you Dmitry. This is your patch updated to HEAD.
Created attachment 169095 [details] Recompiled libs I've tested x86 and x86_64 libs. Wasn't able to test IA64 since I don't have access to such machine.
Created attachment 169107 [details] Patch_v02 Patch containing service segment incrementation for windows fragments.
I now see the error of my ways, the lines: free(rdb); nameString = (*env)->NewString(env, (jchar *)targetName, len); need to be switched, otherwise NewString is accessing memory that has just been freed. Sorry about that.
Created attachment 169113 [details] Patch_v03 Thanks Dmitry.
Created attachment 169121 [details] Recompiled libs
FYI, the test cases which I contributed for symlinks in bug 172062 already have some code to deal with Vista. Id should simply take a bit of uncommenting some lines to enable those unittests (e.g. isWindowsVista()) once the support is in. Note that in order to successfully run those tests, the unittests must run with Admin privileges (because only Administrators can create symlinks on Vista).
Also I think that what's missing from my patch is the update to the attributes() call to return ATTRIBUTE_SYMLINK | ATTRIBUTE_LINK_TARGET (probably would need to detect if running on Vista+)
Would it make sense to also report Windows Junctions as ATTRIBUTE_SYMLINK ? Or just Vista+ Symlinks? As long as the link is read only, they are almost conceptually equivalent. The biggest (and potentially dangerous) difference is that in Windows Explorer, deleting a Junction deletes the content behind the junction whereas deleting a symlink deletes the link (which is expected). Would likely need some extra testing how IFileStore#delete() handles this -- as per its Javadoc this is *required* to not delete content behind an item exposed with ATTRIBUTE_SYMLINK. I've been using Junctions a lot on Win XP with the excellent tool from http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html or the commandline tools from http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx .
I would vote against junctions being symlinks. Junctions are more equivalent to mount points on unix, which should be exposed seperately if needed.
I agree with Dmitry. Exposing junctions as symbolic links is likely to caue more confusion than benefit.
Created attachment 169326 [details] Patch_v04 (In reply to comment #13) > Also I think that what's missing from my patch is the update to the > attributes() call to return ATTRIBUTE_SYMLINK | ATTRIBUTE_LINK_TARGET (probably > would need to detect if running on Vista+) Done. The check is based on GetVersionEx call what means the version returned could not match actual if running in compatibility mode. Dmitry, please review.
Created attachment 169328 [details] Recompiled libs
The code looks ok to me, however according to MSDN (http://msdn.microsoft.com/en-us/library/ms724832%28v=VS.85%29.aspx) testing for the presence of functions associated with the feature we care about is preferable, so probably something like this: HMODULE kernelModule = LoadLibraryW(L"kernel32.dll"); if (kernelModule == NULL) { return attributes; } if (GetProcAddress(kernelModule, "CreateSymbolicLinkW") != NULL) { attributes |= ATTRIBUTE_SYMLINK | ATTRIBUTE_LINK_TARGET; } FreeLibrary(kernelModule) return attributes; However it's a personal preference and I'm ok with leaving the code as it is now.
Created attachment 169368 [details] Patch_v05 (In reply to comment #19)
Created attachment 169369 [details] Recompiled libs
I like the idea of probing for required functions rather than hard-coded version numbers. It seems odd, though, to probe for "CreateSymbolicLinkW" when we really only _read_ symbolic links.
Yes, however it was the closest function that I could find for that feature.
Libs in HEAD. Marking as FIXED.
