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 object 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 object 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)
======================================================================
- duplicates
-
JDK-4313887 New I/O: Improved filesystem interface
- Resolved
- relates to
-
JDK-4379535 File, FileInputStream, FileOutputStream, RandomAccessFile factories for platform dependent behavior
- Closed
-
JDK-4408059 File should be made abstract to allow modeling platform-specific filesystem semantics
- Closed
-
JDK-4084666 Folder class to encapsulate the details of a file on a particular file system
- Closed
-
JDK-4356160 JFileChooser doesn't support shortcuts (.lnk files)
- Resolved
-
JDK-4239752 FileSystem should be a platform-specific class to avoid native code
- Closed