Thunderstone Support Forums

When I tried to delete a profile named fullsiteip (in directory texis/fullsiteip), got the following error messages (at the top of the admin interface window):

008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't delete d:\program files\webinator/texis/fullsiteip\db2\SYSINDEX.tbl: Permission denied in the function VXsysutil 008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't delete d:\program files\webinator/texis/fullsiteip\db2\SYSMETAI.tbl: Permission denied in the function VXsysutil 008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't delete d:\program files\webinator/texis/fullsiteip\db2\SYSPERMS.tbl: Permission denied in the function VXsysutil 008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't delete d:\program files\webinator/texis/fullsiteip\db2\SYSTABLE.tbl: Permission denied in the function VXsysutil 008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't delete d:\program files\webinator/texis/fullsiteip\db2\SYSTRIG.tbl: Permission denied in the function VXsysutil 008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't delete d:\program files\webinator/texis/fullsiteip\db2\SYSUSERS.tbl: Permission denied in the function VXsysutil 008 [webinatoradmin=webinatoradmin](sysutil) 1841: Can't rmdir d:\program files\webinator/texis/fullsiteip\db2: Directory not empty in the function VXsysutil 111 () 1841: Too many messages in the function addputmsg

After it displayed all the errors, it did remove the fullsiteip entry from the list of profiles.

When I looked at the server directories, the /fullsiteip directory existed; in it was a /db2 directory containing about 8 files named sys*.*.

How do I:

1) fix the half-done delete? Is it safe to just delete the fullsiteip directory?
2) prevent this from happening again? I assume it's a permissions issue, although I haven't had any trouble creating profiles.

Yes, you can just remove the fullsiteip directory.

If the database had just been in use then the profile delete may not have allowed enough time for the database to be completely closed, and the database files were still open. You might try adding a short sleep after the <rmlocks> calls, e.g. <sleep 2>, to give it time to close the database.