Menu
▾
▴
#13 Problem deleting directory tree
The following problem was reported by Markus Froschle:
If you drag a multi-level directory tree that contains a readonly file below its lowest node to the trashcan, the operation stops because it encountered that readonly file. So far, so good.
If you then set that file to read/write, you still cannot delete the tree (although you can delete the file now). Even if you deleted the file, you still cannot delete the directory tree.
The readonly status seems to be propagated all the way up to the top node and the only way for the user to get out of that situation is a either reboot or a rename operation on all intermediate directory nodes. Rereading the tree (close window and reopen, ESC key) does not help.
Markus noted that he could not reproduce it under TOS 1.62; however, I saw the same problem under FireTOS (which is 4.04-based).
I believe this is cause by the code that handles the "current directory" table (dirtbl[]). When an Fsfirst() is issued with a wildcard specification, the directory is "locked into" the table by incrementing the usage count. The directory is "unlocked" (usage count decremented) when ENMFIL is returned by Fsnext().
Inspecting dirtbl[] after the situation described above shows that the use count is still 1, so I think the desktop is not continuing until ENMFIL. To be investigated further.
This is a side-effect of EmuTOS's attempt to track in-use directories, which was a kludge. Since later versions of Atari TOS no longer do this, the related code has been removed, and this situation should no longer occur.