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.

Divider

Can't you just try it? – Heteromerous

Strange - writing to a FileInputStream? – Frug

A File only contains a file location; it doesn't maintain any sort of connection to the file, and won't keep a file alive. – Palacios

I'd like to see complete code - including the posted statements - that does write the file. – Frug

@Frug I've included the statement as best I can - though due to security reasons, I can't include the SQL call that initially uploads the CLOB itself. – Divider

@Heteromerous I have. It created the file just as I expected. I'm trying to convince my co-workers that it will work every time, but they're still confused by how the File.delete() method works. – Divider

What about reading the Javadoc of File.delete() to them if they can't read it for themselves? I don't see much leeway for misunderstanding what's written there. – Frug

Ditto what @AasmundEldhuset said. File is a poorly named class because a File instance does not represent (or in any way stand for) a file. A File instance represents a pathname. It should be obvious that deleting a file with a given pathname does not prevent you from subsequently creating a new file that has the same pathname. – Terrarium

@Frug Having read it, I can see how they might get confused by it - Deletes the file or directory denoted by this abstract pathname. If this pathname denotes a directory, then the directory must be empty in order to be deleted - if they don't understand that the File object acts as a pointer to that directory, and that it still acts as a pointer even after invoking this delete method, they might think we're losing the pointer when invoking delete. – Divider

Why should File.delete() be any different that the equivalent function in a file browser, or the cmd interpreter, or the shell, where you call /bin/rm? – Frug

@Frug I'm not sure. They seem convinced now, only after several minutes of confirming that it does in fact work that way, so maybe all I'm really looking for is proof that it does in fact run in that manner at this point. – Divider

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.

Acknowledgment