This is related to, but significantly more ambitious than, bug
report 4089881.

The current API for dealing with files and directories is limited in
certain frustrating ways.  In particular, the inability to detect or
manipulate symbolic links and/or file permissions/acls is particularly
aggrivating, as is the system-dependent file-creation semantics of
FileOutputStream.

So, I propose that you add a new FileSystem class which encapsulates
the abilities and limitations of a particular file system.  Each
FileDescriptor would have a FileSystem  customer  associated with it.
Subclasses of FileSystem could encapsulate the semantics of DOS,
WinNT, UFS, NFS, AFS, etc.  You also add a bunch of capabilities to
FileDescriptors, so you'd probably wind up dealing in subclassed
FileDescriptors as well -- NFSFileDescriptor, etc.

A user should be able to query a FileSystem  customer  to determine its
capabilities/limitations; the interface should be the union of all
conceivable file system operations, with each throwing a
notImplementedException or somesuch for things it can't actually do.

Things I'd want in the FileSystem class:
variations on the UNIX open command:
- create, read, readwrite, write, append, and truncate, which all
  open a file -- create fails if the file exists already, all the others
  fail if it doesn't.  Each returns a FileDescriptor.  You can then
  feed that FD to FileOutputStream or whatever.
- the same things, with a boolean flag or two indicating SYNC
- the ability to create symbolic links to other parts of the hierarchy
- the ability to query whether or not these things are possible in the
  specified filesystem

Things I'd like added to the FileDescriptor class:
- the ability to set file and directory ownership at a user and group level
- the ability to set file and directory permissions as per AFS (this list
  stolen from MIT Project Athena's OLC answers):
        r       read the contents of files in the directory
        l       list the names of files in the directory
        i       insert files into the directory
        d       delete files from the directory
        w       write (or modify) files into the directory
        k       lock (or modify the write-mode bit) of files in the directory
        a       administer or change the acl of the directory

  I'd like to see r,d,w,k, and a available per-file as well, in the 
  event that some filesystem supports that fine level someday.
- the ability to query which of these ops are possible on this filedescriptor
- the ability to set/unset the lock-bit on a file/directory


Really, the details of these things aren't important, so long as
the abilities get there somehow.  Until then, Java apps can't
share files in a restricted way on shared filesystems.
(Review ID: 27411)
======================================================================
Posted Date : 2005-08-25 16:21:57.0

Write JNI interfaces for all operating systems.
(Review ID: 99488)
======================================================================

Yes yes yes yes, but not in JDK 1.2.  Maybe in the next feature release.
--   xxxxx@xxxxx   4/6/1998

there is api similar to the one requested at
http://members.tripod.com/~avdhome/rfsclient.html

This bug makes it impossible to use Forte for Java in my
environment, since we keep all our web pages and servlets
in afs. 

See
JSR 203: More New I/O APIs for the JavaTM Platform ("NIO.2")
http://jcp.org/en/jsr/detail?id=203