To kick off a separate discussion on Alias management...
1) Create/modify aliases
I'm not convinced this is required. The new flexible project structure/existing linked IResources provides equivalent functionality to filesystem aliases, in a more system-portable way than the underlying OS does (if the OS provides them at all). For Eclipse's internal needs this should be sufficient. Filesystem aliases are really a part of the external tools environment Doug talks about--many external tools work directly upon the filesystem and symlinks can be used to provide them the unified view of the world that those external tools need.
2) Provide consistent normalized path support to identify an alias and a target of alias as the same file
This is a definite need, it prevents the problem of multiple editors for the same file thinking they are editing separate files, etc. The problem in Eclipse currently is that some parts normalize paths and others don't, leading to different identities for the same file. To correct this an API for file object/file path comparisons should always compare normalized forms rather than non-normalized forms.
3) Serve up both normalized and non-normalized path strings for a filesystem object
Any view that maps directly to the filesystem (like the Navigator View) needs to represent an alias as a node, so methods like EFS.File.getChildren() would need to return a node for each aliased file. But I'm wondering if the current IResource getLocation()/getPath() distinction can manage the alias vs. resolved names at the Project level rather than the EFS level, so that the identity returned by an EFS file object is always its fully resolved path. (Lots of room for discussion here.)
4) Support team providers for VCSs that can check in symlinks
What support do team providers need from EFS to manage aliases? It seems like any team provider will call an existing non-EFS based API to manage actual file transfers, but if not then there may be a need for direct EFS support.
Cheers,
Terry
