Does File.delete() delete the pointer of the File object?

Question

My co-workers and I are having an argument about how the File.delete() method works in Java.

In our code:

File outFile = new File("/dir/name.ext");
if(outFile.exists())
    outFile.delete();

FileInputStream inStream = new FileInputStream(outFile);

WriteFile.writeFile(inStream); // Writes the actual file

I can't include the entire method body of writeFile here for security reasons, but after it creates the database object needed, it performs the following action:

BufferedOutputStream out = null;

Object[] args = {"an_encrypted_data_clob_name_in_the_database"};
Class[] argTypes = {Class.forName("java.lang.String")};
Object result = WSCallHelper.jdbcCall(null, rs, "getCLOB", args, argTypes);
CLOB clob = (CLOB)result;
out = new BufferedOutputStream(clob.getAsciiOutputStream());

byte[] buffer = new byte[512];
int bytesRead = -1;

while((bytesRead = inStream.read(buffer)) > -1)
    out.write(buffer, 0, bytesRead);

I know it's a little unclear, but the general gist of it is that it creates an AsciiOutputStream of the Clob (yes it's supposed to be a Clob) and writes it to the inStream object that is passed from the previous method.

They're convinced that this won't write to the file directory because of the File.delete(); method, but I know for a fact that there was a file in that location yesterday, and this code ran today and wrote a file in that exact location. Because, although the actual file is deleted, the pointer for where that file is located is still in outFile, and the creation of inStream with outFile makes inStream point to that location.

Is there any reason to believe that this file wouldn't be written in this scenario? Ideally, I'd like some proof that the delete() method removes a file that the File object points to, not the pointer itself.

Answer 1

java.io.File is not a file pointer, nor does it hold a file pointer. It is an immutable pathname.

An abstract representation of file and directory pathnames.

Instances of this class may or may not denote an actual file-system object such as a file or a directory.

Instances of the File class are immutable; that is, once created, the abstract pathname represented by a File object will never change.

With the source code for File, we can see it is a wrapper around a String.

delete cannot remove a file pointer because there is no file pointer.

Deletes the file or directory denoted by this abstract pathname.

Connections to open files are represented by java.io.FileDescriptor:

Instances of the file descriptor class serve as an opaque handle to the underlying machine-specific structure representing an open file […].

This is how input/output streams interact with the file system, not through File, for example FileOutputStream(File) explains the following:

Creates a file output stream to write to the file represented by the specified File object. A new FileDescriptor object is created to represent this file connection.

If the file […] does not exist but cannot be created, or cannot be opened for any other reason then a FileNotFoundException is thrown.

And we can observe that, for example, the constructor for FileOutputStream that is delegated to merely gets the path String from the File, checks if it's valid, then discards the File:

public FileOutputStream(File file, boolean append)
    throws FileNotFoundException
{
    String name = (file != null ? file.getPath() : null);
    SecurityManager security = System.getSecurityManager();
    if (security != null) {
        security.checkWrite(name);
    }
    if (name == null) {
        throw new NullPointerException();
    }
    if (file.isInvalid()) {
        throw new FileNotFoundException("Invalid file path");
    }
    this.fd = new FileDescriptor();
    fd.attach(this);
    this.append = append;
    open(name, append);
}

There's no documentation to support the idea that java.io.File represents a file pointer. ; )

We also know that an open handle to a file is a resource that must be released at some point, but File does not provide a means to do so; ergo, File does not fit our notion of what a file pointer should be.