Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 366781 - Internal method isReadOnly(File) doesn't work as expected on Windows
Summary: Internal method isReadOnly(File) doesn't work as expected on Windows
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: 3.7.1   Edit
Hardware: PC Windows All
: P3 normal (vote)
Target Milestone: Juno   Edit
Assignee: Meng Xin Zhu CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 351944
  Show dependency tree
 
Reported: 2011-12-15 02:14 EST by Meng Xin Zhu CLA
Modified: 2013-11-10 22:31 EST (History)
2 users (show)

See Also:

Attachments
a proposed patch (3.46 KB, patch)
2011-12-15 22:29 EST, Meng Xin Zhu CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Meng Xin Zhu CLA 2011-12-15 02:14:23 EST 
org.eclipse.equinox.internal.p2.artifact.repository.Activator.isReadOnly(File) is a method to determines the given file whether is read-only, then create the read-only Location instances based on its checking result. For example, the file is UNC style that is read-only shared by another Windows machine, say as \\windows_host\myshare\.

There are several Java bugs[1][2] reported File.canWrite()/canRead()/canExecute() have problems on Windows. NIO API FileChannel.tryLock should work. Or refer to how Locker does.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6368018
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6203387
Comment 1 Henrik Lindberg CLA 2011-12-15 12:32:28 EST 
This may be the cause for some of the reported problems relating to the p2 backup/restore functionality as well. (Have not actually scanned that logic to check how it determines what can / can't be done with the files, but would not be surprised if it makes use of File.canRead()/canWrite()).
Comment 2 Henrik Lindberg CLA 2011-12-15 12:33:17 EST 
(In reply to comment #1)
> be surprised if it makes use of File.canRead()/canWrite()).
    be surprised if it does *not* make use of ....
Comment 3 Meng Xin Zhu CLA 2011-12-15 22:29:53 EST 
Created attachment 208477 [details]
a proposed patch

I don't find better way without creating a temporary file for testing. Does everyone have better solution to check whether new files can be created under a specified folder?
Comment 4 DJ Houghton CLA 2011-12-16 11:11:46 EST 
No, I think that's the best option. Doing a search returns a couple of other places in our code where we try and create a temp file to determine if a location is readonly.

org.eclipse.core.internal.runtime.auth.AuthorizationDatabase#canWrite
org.eclipse.osgi.internal.baseadaptor.AdaptorUtil#canWrite

Check out the code for the second one, it has special considerations for DLLs on certain Windows-based file systems. Not sure if we need that or not in the p2 code.
Comment 5 Meng Xin Zhu CLA 2011-12-18 22:42:36 EST 
(In reply to comment #4)
> org.eclipse.core.internal.runtime.auth.AuthorizationDatabase#canWrite
> org.eclipse.osgi.internal.baseadaptor.AdaptorUtil#canWrite
> 
> Check out the code for the second one, it has special considerations for DLLs on
> certain Windows-based file systems. Not sure if we need that or not in the p2
> code.
If Eclipse is installed into "Program Files" by user on Windows 7, the instance of this Eclipse always is read-only when user launches it in normal way. The base Eclipse should not be locked and updated when user launches Eclipse without administrative permission.

Fixed, http://git.eclipse.org/c/equinox/rt.equinox.p2.git/commit/?id=4174108261eddcb3cd45006d5f1f7631e4a2a2d9