I've tried this, but the files are not expired on the server (no Expiring ---> message in the dsmsched.log). The unexpected or unpleasant side effects that I am referring to are actually expiring the files on the server - maybe people didn't expect this to work this way? Principle of least astonishment? Should I expect to see expiring messages or a change in the number of files expired (when I run the incremental manually)? When I change the dsm.opt and run either the scheduled incremental or a manual incremental, run the server expiration, then check from the client, the files I want to get rid of are still there, both active and inactive versions.
I don't have a problem with excluding a directory. My problem is getting the files to expire on the server after I have excluded the directory. I want to be able to modify the client dsm.opt file (or in our case, put these statements in a client option set) to implement our new policy, and then run an expire command on each client to force the expiration of the files on the server that aren't part of the new policy.
I can do this if I specify each and every directory and subdirectory on the client, but this could run into the thousands and would be different on each computer. I need the client expire command to support directory wildcards or recognize the -subir=yes option. Maybe the exclude on the client should force the expiration of those files on the server?
Andrew Raibeck wrote:
Gretchen, I don't understand the following:
Prior to the v4.2 client, you could simply exclude the files on the client side and the files would be expired. This probably led to unpleasant/unexpected results, so this doesn't work anymore and the client expire was introduced.
What unpleasant/unexpected results are you referring to? If no longer wish to back up files in c:\junk and it's subdirectories, then I don't see why using EXCLUDE.DIR wouldn't work. You could use a client options set to do this.
Gretchen Thiele Princeton University
