and like that, its gone
DELETE_OBJECT today. As it suggested, it deletes things - its the power behind the
C:Delete command. I’m actually quite pleased with how straightforward it was to put together - it suggests that I have the internal API for updating directories and writing things right. The process is to find the entry, delete it, delete any associated long name entries, and then free all the clusters the file was using. In practice its slightly more complicated - the file can’t be in use, if its a directory it must be empty, etc - but its mostly quite pleasant.
One big philosophical change I made today was to make it so the current directory (
.) and parent directory (
..) entries are never ever exposed to DOS. It was just confusing things - DOS has its own understanding of how to move to a parent directory (
/), and thought that moving to
.. was moving to a subdirectory. It meant having special checks everywhere to make sure you didn’t try to actually operate on these entries (eg try to delete them). In the end it makes sense if they don’t exist, so now the internal function
TryLockObj(), which looks for files by name and locks them, will always return
ERROR_OBJECT_NOT_FOUND for one of these files. Similarly,
GetNextDirEntry() which is used when enumerating all the files in a directory will skip over the dot entries. The only place now where the
.. entry is used is in the internal
GetParentDir() function, and it finds the entry manually.
Removing input checking code while making things less confusing for the user is not something you get to do often, so I’m pretty happy with the change :)