Hi Martin,
Those proposed API additions look good. Thanks also for the link to bug 233939. Your solution (I'll call it 'store canonical roots') should work well for the scenarios I posed--it allows you to quickly lookup an IResource via its canonical path, and if there are multiple IResources mapped to a single canonical path, you can get the whole list and either either do a group resource operation or select one based on your UI context.
It doesn't directly solve the issue of editing "/project1/external_lib/header.h" and "/project2/external_lib/header.h" (which symlink to the same file) at the same time, and an edit to one being immediately reflected in the other. In that case the files are represented by two different IResources and their underlying connection can only be determined by querying the underlying IFileStore level. But that sounds fine, calling
boolean IFileStore#isSameFile(IFileStore other) for all other resources open in editors should be fairly quick.
I don't really know what to do about hard links either. You can't treat them the same as symlinks since there is no real canonical path. Tar correctly restores a hard link's inode to avoid duplicated file contents. My guess is that the right model is that hard links are separate files that just magically share the same content.
isSameFile() might be the right way to properly query about changes to this shared content. Does anyone have any use cases?
As for persistence and transferability to another workstation, we should be able to persist symlinks that are relative paths in the same relative format, and then read them out into absolute paths when creating the canonical roots.
--Terry
On Thu, Oct 16, 2008 at 10:10 AM, Oberhuber, Martin <
Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
> Hi Terry,
>
> after more investigations, I believe that we should make the following
> additions
> to EFS:
>
> String IFileStore#getCanonicalPath() throws CoreException
> Will be necessary for IWorkspace.findFilesForLocation() if a filesystem has
> symlinks.
> If we want to introduce this in a fully compatible fashion, we could also
> think about doing
> IFileInfo#getStringAttribute(EFS.ATTRIBUTE_CANONICAL_PATH)
> instead.
> Object IFileInfo#fileKey()
> A unique key identifying a file (e.g. on UNIX: Device ID + INode number), or
> null if not available.
> Can be used to determine with least effort whether two files are the same,
> e.g. in order to
> avoid cycles due to symbolic links when walking a file tree. I've had that
> idea for a very
> long time, and seeing it in JSR203 confirms for me that this is worthwhile.
> boolean IFileStore#isSameFile(IFileStore other) throws CoreException
> Also for checking link cycles and fixing issues with case (in)sensitive file
> names.
> More efficient than doing getCanonicalPath() on both file stores... we might
> acutally get away without this API since it's only about efficiency.
> boolean IFileInfo#getAttribute(EFS.ATTRIBUTE_SPECIAL_FILE)
> For files that are neither a directory nor regular file nor symbolic link
> (such as named
> pipes, Unix domain sockets, or devices). These should get special treatment.
> boolean IFileStore#createSymbolicLink(String linkTarget, int options,
> IProgressMonitor mon) throws CoreException
> I think we need this for properly importing from file system / tar archive
> into workspace.
>
> I'm not so sure any more if we really need more asynchronous support. What
> we might need,
> though, is some API around manipulation of file system paths (resolving,
> concatenating, stripping)
> as well as some Monitoring API.
>
>> * IFileStore.isAlias() -- much lighter weight than getting
>> the canonical path, only returns true if last segment is aliased
>
> I think we have this already, with
> boolean IFileInfo#getAttribute(EFS.ATTRIBUTE_SYMLINK)
> I'm not exactly sure how we could be dealing with hard links -- the
> fileKey() and
> isSameFile() methods could help here, or we treat all kinds of aliases with
> ATTRIBUTE_SYMLINK... I'm not sure. Hard links are also the same concept
> as what McQ mentioned on system/i -- the very same file referenced in both
> a case sensitive and case insensitive manner by different file paths.
>
> I think that your other requirements are basically covered by
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233939#c9
> and the bugs referenced from there.
>
> Cheers,
> --
> Martin Oberhuber, Senior Member of Technical Staff, Wind River
> Target Management Project Lead, DSDP PMC Member
>
http://www.eclipse.org/dsdp/tm
>
>
>
> ________________________________
> From:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx> [mailto:
eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx] On Behalf Of Terry
> Parker
> Sent: Wednesday, October 08, 2008 8:42 PM
> To: E4 developer list
> Subject: Re: [eclipse-incubator-e4-dev] [resources] Alias management
>
> Hi Martin,
>
> Thanks for your comments. Keeping the file system layer stateless is the
> right approach. I think the following additions would be sufficient:
> * IFileStore.getCanonicalPath()
> * IFileStore.isAlias() -- much lighter weight than getting
> the canonical path, only returns true if last segment is aliased
>
> A big concern I have is that if the resource layer solely adds
> getCanonicalPath() to existing methods, it won't get invoked consistently.
> Perhaps having {IWorkspace,IProject}.findResource(String absolutePath) API
> calls as the primary/only way to convert a path string to a resource would
> provide the consistency we need.
> Here are some scenarios for which we will want aliasing to work correctly:
>
> A) The file "/real/myfile.cc" is symlinked by "/project_alias/myfile.cc".
> Desired behavior:
> * When a debugger returns the path "/real/myfile.cc", the debug framework
> opens the resource associated with project_alias, not a separate resource
> outside the workspace
>
> B) "/project/external_lib/headers" is symlinked to the folder
> "/project/external_lib/v1234/src/headers".
> "/project/external_lib/v1234/src/headers/file_with_syntax_error.h" fails to
> compile. Desired behavior:
> * Clicking on a console hyperlink or a Problems pane item for the
> error opens the workspace-mapped resource. (This is no different from A,
> but illustrates that symlinks can occur in any segment in a path, not just
> the end segment.)
> C) "/project1/external_lib/headers" and "/project2/external_lib/headers" are
> both symlinked to the folder "/project1/external_lib/v1234/src/headers". On
> a build of project1, code in an #ifdef in
> "/project/external_lib/v1234/src/headers/header.h" fails to compile. Desired
> behavior:
> * You get two different editor panes when
> opening "/project1/external_lib/headers/header.h"
> and "/project1/external_lib/headers/header.h", since they may be used with
> different compilation directives, which would affect their display
> * Clicking on a console hyperlink or a problems pane item for the
> error opens the workspace-mapped resource for the project1 version of the
> file
> * Editing the "header.h" file updates both editors in concert
>
> --Terry
>
> On Tue, Oct 7, 2008 at 10:31 AM, Oberhuber, Martin
> <
Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
>>
>> Hi Terry,
>>
>> I fully agree.
>>
>> Create / Modify Aliases. I also don't see a need for creating / modifying
>> file system links from Eclipse. There should be support for visualizing
>> them, though (which is easy to add in Eclipse 3.5 already).
>> Consistent normalized path support. Agree. We'll need
>> IFileStore#getCanonicalPath() on the EFS API, and we'll need smart
>> algorithms on the Resource / Refresh / Compare code to avoid using
>> getCanonicalPath() where possible, in order to maintain good performance. In
>> other words, query the canonical path only when we come across an FS link,
>> but construct the path ourselves for "regular" files and folders. The
>> Workspace Tree will need some redesign to understand links "moving around"
>> its structure.
>> Serve up both normalized and non-normalized path strings. Yes, though I
>> think this is probably more relevant for resource objects than for
>> filesystem objects -- the FS layer does exactly that with a
>> getCanonicalPath() API already, but since FS must be stateless it will be
>> expensive. On the Resource layer, we can add state (caching) to make it
>> faster.
>> * the non-normalized path is how the client / user originally referred to
>> a resource, and
>> * the normalized path is its normalized variant (can be computed from the
>> workspace tree).
>> Support team providers for VCSs that can check in symlinks. I'm not sure
>> if that is required. Assuming that foo/bar is a symlink, doing a "checkin
>> foo/bar" will check in the symlink as needed. To me, it seems that all we
>> need to make sure is that we don't instruct the VCS to check in the same
>> file twice just because we approach a given (normalized) file through
>> multiple different (non-normalized) paths. This should be possible through
>> an improved alias-aware Workspace Tree.
>>
>> I think that if we are careful, there is some potential to even add proper
>> Alias Management in Eclipse 3.5 already, though that needs a lot more
>> investigation. What I would propose, is starting that work soon in order to
>> see whether we can apply it to Galileo already or whether it requires more
>> radical change that would make it impossible in 3.5.
>>
>> Cheers,
>> --
>> Martin Oberhuber, Senior Member of Technical Staff, Wind River
>> Target Management Project Lead, DSDP PMC Member
>>
http://www.eclipse.org/dsdp/tm>>
>> _______________________________________________
>> eclipse-incubator-e4-dev mailing list
>>
eclipse-incubator-e4-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>>
>
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
>
eclipse-incubator-e4-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev>
>
