Bug 26933 - [resources] IResource.copy should default to copy underlying contents of linked resources
Summary: [resources] IResource.copy should default to copy underlying contents of link...
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 2.1 M4   Edit
Assignee: John Arthorne CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-11-22 06:56 EST by Jerome Lanneluc CLA
Modified: 2002-11-25 11:50 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jerome Lanneluc CLA 2002-11-22 06:56:37 EST
Build 20021119

You have to specify IResource.DEEP to copy the underlying contents of linked 
resources. Existing clients that are not aware of linked resources will be 
caught by this. 

I think the default should be to copy the underlying contents of linked 
resources, and IResource.SHALOW would allow clients that are aware of linked 
resources to only copy the link.
Comment 1 John Arthorne CLA 2002-11-22 12:02:27 EST
The expected behaviour on link copy is a shallow copy.  When you copy a windows
shortcut or a unix symbolic link, it will perform a shallow copy.  Copying
underlying contents is not usually supported.  That's why we want shallow copy
to be the default behaviour, and DEEP requires an extra flag.  Generally, if the
user tries to copy linked resources into a place where linked resources are not
permitted, we want them to get back an error, ("Linked resources must be direct
children of a project").  In general, people are using linked resources because
they have a requirement that their resources remain in that particular location,
so unexpectedly changing location (deep copy) is not generally what they want. 
Only in certain special cases should a deep copy happen "for free" (copying
resources to java output folder being the prime example).  Are there other cases
in the java model where you think deep copy is necessary?

Jim, any further comments on this?
Comment 2 Jerome Lanneluc CLA 2002-11-25 06:04:20 EST
My point was just that every single client of Platform/CORE (including the Java 
Builder and the Java Model) is going to have to adapt to this behavior, whereas 
an automatic deep copy would make it transparent.

If the Workbench wants to have the same behavior as the Windows explorer, it 
will have to first make sure that linked resources render differently, then (if 
the default was a deep copy) it could use the SHALLOW flag.
Comment 3 John Arthorne CLA 2002-11-25 11:50:07 EST
Ok, the default is now a DEEP copy, and a new IResource.SHALLOW flag has been
added to get the opposite effect.  The DEEP flag has been deprecated, and will
be removed after the next integration build.  These changes have been released
to the HEAD stream.

This change does NOT make linked resources transparent for users of our API, but
it will prevent CoreExceptions occurring for clients that are not yet aware of
linked resources.  Up to date clients will still need to revisit their uses of
copy and move to decide if they need to do a shallow or deep copy/move.  In most
cases, the shallow version will make more sense (for example when copying/moving
a project).  Clients that have UI for copy/move will usually present the choice
of shallow or deep to the user.  End users will generally expect shallow
copy/move to occur, as this is the behaviour of copying and moving linked files
under most operating systems (shortcuts or symbolic links).