>I'm assuming that the folder is the temporary IE folder. If so, the return code makes sense. In general it mean access/permission denied. As I mentioned in my initial post, trying to delete system folders is not something I would be in favor of trying. In this case, it isn't the fact that the system attribute is set. It's the fact that, in this instance, the folder is protected by the OS. IOW, you can't delete it.

I'd tend to agree - it's definitely possible that a user might be permitted to clear the content of the folder, the OS may refuse to remove the folder itself, whether based on permissions granted for the folder object, or the presense of specific folder properties (ie the System attribute.) another possibility is that the location is the user-visible resolution of a system CSIDL, whichdeclares a path for file and folder objects relative to the CSIDL, does not point to the actual location of the CSIDL it refers to - IOW, a relative path is OK, but the absolute pathisn't located where the user expects to find it - it's like the My Documents directory for machine accessed by different users - each one sees a "My Documents" folder and Desktop, but it isn't the same one a different user is referenced under that name.

I'd start by retrieving the full path of the temporary IE folder given to the user (both via the FSO, and via the API SHGetFolderPath or SHGetFolderLocation() based on the CSIDL for CSIDL_INTERNET (0x0001) or CSIDL_INTERNET_CACHE (0x0020), examine the attributes of the folder, and check the permissions and rights allowed for the user in question if either an NT-derivative OS (NT/2K/XP) or a Win9x system with user-level permissions and user profiles enabled got the error.