Community
Participate
Working Groups
When copying a file that is read only, the newly created file is marked as read only too. I would have expected it to be writeable. In addition, if a java file is copied through the Java Package Browser, the package information cannot be updated, resulting in an incorrect java file.
Behaviour in Win98 and Linux is that the destination file is also read-only. Is there a particular use case or filesystem that you are using where you do not see the read-only attribute copied?
This seems to be the desired behaviour. Copying directly in Windows 2000/NT has the same effect. See also: bug 6058 - copying IFolder loses read-only flag setting which reports the opposite behaviour as a defect.
Moving to JDT/UI for comments on second problem. (moving a Java file causes the package information to be incorrect)
I agree with Birgit, at least when performing a copy in the JDT UI. One of the advantage of using the copy (rename and move also) features in the Java perspective is the refactoring that takes place to insure that the correct package, class name, and constructors are maintained. Our VCM is clearcase and we develop right on top of the 'repository'. This means that the only way to make a file writable is to check it out. It is not desirable to be forced to checkout a file simply to copy it. If the copy is performed without the checkout. The new file will not compile. I could see an argument for maintaining the read-only status for files copied in the Resource perspective. However, the semantics of copy in the Java perspective are very different. A Java perspective copy implicitly changes a file and therefore needs to remove the read-only attribute. The behavior in Win NT seems to be dependent on the file system. When using explorer to copy a file in an NTFS partition, the read-only attribute. However, when you copy a file in a clearcase view (they have their own file system.) The new file does not have the read-only attribute.
*** This bug has been marked as a duplicate of 4210 ***
