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