I would like to have simple calls to set the
permissions on a file.

i.e.
	setWritable
	setReadable
	setExecutable?

There are ways of requesting this info in 
java.io.File, but no ways of setting them.
Ideally, it would be nice to full chmod
capability, but failing that at least a
simple set read/writeable.
(Review ID: 14921)
======================================================================

The current functionality for accessing files
and file systems is rather limited. I belive it
is possible to evolve it to a more full functionality
and still keep it platform independent.

Java is no longer percieved as a language only for
accessing the web. It will be used for state-of-
the-art application and system development.
For this purpose, it need to have - in principle -
the same capabilities as a native platform.

The current io package cannot handle file access
rights for users, groups, etc. The original reason
for this lack of functionality may have been to
keep Java platform independent. It may take some
work, but it is possible to get this functionality
in a almost platform independent manner.

I would like to know if there is any work currently
going on in this area?

My first few (very early) ideas in this line
follows below.

I actually belive that it is possible to - for example -
implement a file system browser which is plattform
independent, with the functionality to completly
replace a platform specific file system browser.

I also belive that it is possible to deliver platoform
independent programs with platform specific bundles
to configure the platform dependent file system
support.

The general architechture idea is as follows.

Develope a abstract file system interface 
with access capabilities in three layers.
These layers progressivly adds capabilities
or concepts for access rights.

Layers:

 1) No user, group concepts.

 2) User and group concepts with the functionality
    of UNIX and NFS.

 3) Access Control Lists and functionality of
    Windows NT and standards such as the Orange Book.

The idea is that a program can manipulate the file
system with metods of the highest layer, and get
the results of the layer supported by the platform.

A user with a GUI will see and manipulate the file
system at the functionality supported by the platform.

A program without a GUI man be delivered with a
resource bundle specifying platform specific
file system details of which the program is not
aware. For example, by installing users and groups
which owns files created by the program.

You may note that the work amounts to specify
a file system in Java. It is platform specific
in the meaning that it isn't modelled after
a specific platform. But it cannot be done
without specifying a model architecture for
the file system. In practice, this will not cause
any great concern since different operating systems
doesn't seems to differ greatly in the concepts
used.
  xxxxx@xxxxx   10/15/04 20:40 GMT

Drop into native methods.  (Which we have had
to do).
======================================================================

This issue will be addressed as part of the New I/O work.
--   xxxxx@xxxxx   2000/3/9

This is the only feature keeping our product from being 100% Java.

On a Windows 95 system, you can use a wrapper around \windows\command.com:
private boolean changeReadOnly( File dir, String filespec, boolean makeRO )
{
  Runtime rt;
  Process proc;
  int exitcode;
  String dirpath;
  String[] attrib = new String[2];
		
  attrib[0] = "c:\\windows\\command\\attrib.exe";
		
  if ( makeRO )
    attrib[1] = "+R";
  else
    attrib[1] = "-R";
  try
  {
    dirpath = dir.getCanonicalPath();
    attrib[1] = attrib[1] + " \"" + dirpath + "\\" +
filespec + "\"";
    rt = Runtime.getRuntime();
    proc = rt.exec( attrib );
    proc.waitFor();
    exitcode = proc.exitValue();
  }
  catch( Exception e )
  {
    return( false );
  }
  return( exitcode == 0 );
}

How unfortunate that this bug gets so few votes.
We really, really need this to be 100% Java.
Seems like such an obvious feature, it's odd that
it was omitted.  Please add the feature as soon
as possible.

This is one feature which is badly lacking in otherwise 
good language like java.Without this feature the funtionality of java in file 
I/O is limited.I suggest that this feature be added immediately.

Don't want to have to handle file permissions per native platform.  It seems
logical to have such a feature in File I/O.  Please consider implementing. 

Note that the workarounds for this bug, using native methods and/or
Runtime.exec() both prevent apps from being certified as Pure Java.  This is a
significant omission stifles a lot of development.

When using the work-around specified (attrib.exe) & an application like MS
Word has the file open the runtime process hangs because of a prompt 
associated with the attrib command. This occurs on Windows 95 and not Windows
NT. Have not tested Windows 98.
Test:
1. Open a writable ".doc" file
2. In a command prompt enter "attrib <filename> +r"
3. You will receive the following response -
    Sharing violation... abort, retry, fail?
    Note: same thing happens with a read-only file & -r
4. The process hangs around until the machine is rebooted. One process for
every time this occurs!

It should also be possible to modify a file so
that (if supported) it is readable/writable only
by the owner.  Consider, for instance, the ~/.keystore
file created by keytool.

What can I say that hasn't been said? I am stunned that this does not exist. It
is a royal pain in the behind.

We develop a product on both NT and Solaris. There is no 
way I can even use the Runtime.exec() "workaround" without 
supporting both attrib and chmod (and thus forcing 
knowledge of what platform I am running on). I can't 
believe this feature is still not in the language, need I 
say more?

I am writing code which modifies Unix shell scripts. Need 
functionality of ensuring that the resulting file has 
executable permission.

Trying to port away from J++ and its native
calls into Win32.

It seems a file can be set "readonly" but 
once done, it CANNOT then be set "readwrite".
This should have been sorted by now !

I guess the work around to do some sort
of "copy, delete, rename" kludge.

Sorry but it is kinda frustrating ...