Community
Participate
Working Groups
- copy-paste a read-only package -> the copy of the package is not read-only (this is inconsistent with the behaviour for at least source folders and java files)
strange, bug 6058 says it's fixed
it works with ordinary folders but it doesn't work with packages
it'd be a jcore issue then - but bug 6060 says they're the same
How is the package copy implemented by the Package Explorer? Since for core there is no such thing as a package, it looks like the problem relies in the way JDT UI implements package copy. Does it create all folders and copy only the files and sub-packages? Or does it create all folders for the parent package in the destination and then copy the package folder?
we call IPackageFragment:copy from jcore
Moving to JDT/Core for comment.
The problem seems to come from private void createNeededPackageFragments(IPackageFragmentRoot, String, boolean). This method is using createFolder, but it doesn't check if the source is read-only. So it doesn't persist the existing flags for the newly created folder.
Olivier - pls investigate
This is more general than simply persist the read-only flag. We need an API from core to persist the attribute of a folder. When we copy the package fragment a.b.c to its destination, we need to create manually the structure of folders. We cannot simply use a core operation to do it, because a.b.c.d is not part of the package fragment, but it is a subfolder of a/b/c and therefore the copy from core would copy the contents of a.b.c.d as well. The problem we have right now is that even if we can create the package structure, we cannot persist all its attributes. We could hack the code for the read-only flag, but what about the hidden flag or the archive flag. We don't have this granularity. I found the way core does this in case you copy a folder from one place to another. It uses a native call and the class is internal, so I cannot use it. I am talking about the class org.eclipse.core.internal.localstore.CoreFileSystemLibrary and its method copyAttributes(String source, String destination, boolean copyLastModified). Would it be possible to have such an API?
Now I got it. Well, I don't think the solution proposed to bug 26100 will make your life any easier, because (if released) it will only work for files. But if, as you suggested, access to #copyAttributes were made available through API, we wouldn't need that other API change anyway. The caveat is that #copyAttributes is implemented only on Windows/Linux. Maybe we will have to wait until a more comprehensive and explicit API for file system management in Eclipse is eventually made available (post-2.1). The main problem here is that we don't have support from Java for that.
Fixed and released in 2.1 stream. This needs to be revisited when Platform/Core will provide a way to "copy" attributes. Move to Platform/Core for adding the appropriate support.
This will not be address for R2.1. Old Summary: copy of read-only package doesn't preserve read-only flag
New API is now on IResource so I believe this is covered. *** This bug has been marked as a duplicate of 26100 ***
