This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Have the following structure on disk: /temp/a/b/test.txt. Set the file 'test.txt' as Read Only (chmod a-w on unix). Now go to Files or Favorites view, Cut the folder 'a' and Paste is somewhere, e.g. to /temp/x. The file r.txt disappears from disk.
Interesting bug.
Date: 2006/07/28 14:48:14 Author: jtulach Branch: HEAD Tag: (none) Log: #81241: Recursive delete shall leave read only files untouched Members: src/org/openide/loaders/DataFolder.java:1.53->1.54 test/unit/src/org/openide/loaders/DataReadOnlyTest.java:INITIAL->1.1
Should be fixed in 5.5 as well, I guess.
Checking in src/org/openide/loaders/DataFolder.java; /cvs/openide/loaders/src/org/openide/loaders/DataFolder.java,v <-- DataFolder.java new revision: 1.38.2.2.2.2; previous revision: 1.38.2.2.2.1 done Checking in test/unit/src/org/openide/loaders/DataReadOnlyTest.java; /cvs/openide/loaders/test/unit/src/org/openide/loaders/DataReadOnlyTest.java,v <-- DataReadOnlyTest.java new revision: 1.1.2.1; previous revision: 1.1
Hmm, that's a wild fix, in fact, but at least prevents data loss. But the fact that you had to fix it this way clearly shows what's wrong: refusal to move read-only files. r/o file is perfectly movable and deletable as you see, so we probably need to reconsider the logic in MultiDO. You can't move a file if its parent folder is r/o. On the other hand, if "b" (from the original steps) is read only, you can still move "a" to "x" and this way "move" both "b" and test.txt, regardless of their access rights. The question is, how does other OSes (windows) behave in this regard.