1

What is supposed to happen to an executable that deletes itself as part of its execution? Are the rules different for different OSes? Does it depend on the executable format (eg PE, Mach-O, etc) or on something else?

Specifically, I want to know about the expected behavior for a self-deleting executable in OS X, Linux, and Windows. If they are different, I want to know why.

motivation:

I work on a project that has a "nuclear" build clean up command:

jlpm clean:slate

The above command completely cleans up and uninstalls everything related to the project, including the jlpm executable itself. On OS X/Linux the clean:slate command works fine, but I've been told it doesn't work on Windows. I'm curious as to why, and how I should go about fixing it

tel
  • 13,005
  • 2
  • 44
  • 62

1 Answers1

4

Are the rules different for different OSes?

Yes.

Does it depend on the executable format (eg PE, Mach-O, etc)

No, executable format is irrelevant.

Traditional UNIX implementations keep a reference count on the file inode. When a regular file is on disk and no program has opened it, it has a reference count of 1 (assuming there are no hard links to it). The 1 comes from directory in which the file appears.

If you then rm the file, the inode reference count drops to 0, which signals to the OS that it is no longer needed, and all data associated with it can be discarded.

When some program opens the file (or the file is executing), the inode reference count is incremented (now 2). If you now remove the file from directory, inode reference count drops to 1, but the file is still there, so there is no problem.

(This is how you could hog disk space on a machine in a way that is "invisible" to the system administrator.)

Windows do not have such reference counting, and attempts to remove open file fail. This causes no end of problems for UNIX programmers.

how I should go about fixing it

See answers to this question.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362