Re: As in...
Originally posted by RiseAgainst
Turning on root in Netinfo Manager and logging on through the log on screen as root. For some reason I was not able to delete the file through the GUI. But the terminal worked. Y is that?
I think it is because of a feature of all versions of Unix, having to do with how files are deleted. I'll explain the background and then my theory.
Unix files really have two parts, which you can think of as the metadata and the data. The metadata includes the name of the file, its owner and permissions, and access dates. The data is the content of the file. The metadata is what you see in a directory listing. When a file is opened by a process (an application, a background task, or the operating system), it is the data that is in use, not the metadata.
When you are allowed to delete a file according to its Unix-level permissions, and you use the
rm command in the
Terminal window, Unix deletes the metadata of the file you name. Normally, the data is deleted too. However, if any processes have the file open, the metadata is still removed but the data is marked for deletion instead of being deleted immediately. It is deleted when the last process closes the file.
My theory is that the Finder has its own method: that if any process has the file open or if the file has properties known by the Finder that tell the Finder not to delete the file, the Finder says no and doesn't try to delete the file. So that's why the Finder fails and
rm works. Utility programs that delete files ignore the Finder properties and do a Unix-level delete.
Just to be thorough, I should mention one more detail. A given data file can actually have more than one set of metadata, i.e., a file can have more than one filename. When one file has two names, it is called a "hard link" between the names. (This is not the same as a "soft link" and not the same as a Mac OS alias.) If you use the
rm command and there are hard links to the file you are deleting, the metadata of the file you name will be deleted and the data will be left as is, since it has at least one other filename pointing to it.
