This may help...?
Having a bit of a mare, and probably can't see the wood for the trees. But I'm trying to remove delete permissions for users, so that they can't delete any files from their home drives (don't ask). This I can do fine with denying the DELETE priviledge to the STUDENT group in the file system properites of the share, but however this means that every document that they open up, creates a temp file, and on closing, even logging off, the temp files aren't removed. So I wrote a tiny batch to delete *.tmp, and run as a logoff script, however as this is a loggoff script, it runs with the same users credentials, so therefore, does not delete anything. Can not put it in a shutdown script, as the temp files are on the share/not the local profile on the workstation (besides, the machines aren't always shutdown after a session). DOHH!
I know I could schedule a massicare of the tmp files at night across the entire drive, but would prefer not to have to do this.
Anyone got any ideas, I've not had much time to dedicate to coming up with a work around.
Any help would be appreciated.
Thanks for the post. This is essentially what I have already done, and works for the purpose of stopping the deleting of items, however, the bones of the problem I have due to this, is that document temp files, are created when users open files from their home drive, are not deleted when the document is closed or even when the session is logged off. This means that all the users home folders will quickly pile up with tmp files, and I want to try and avoid a mass find/delete scheduled nightly task to remove them and have them cleared when the attributed document is closed, or at least when the user logs off.
I think you can use file screening to prevent certainly office programs from creating the temporary files at all. If you block .tmp files or ~*.* files they wont be created which I don't believe actually impacts usability.
That is currently my ownly resort, however, we are sometimes clocking up GBs of tmp files and we are on the limits of our current storage capabilities.
Chris, thanks, I'll try this.
There are currently 1 users browsing this thread. (0 members and 1 guests)