>> On Tue, 6 May 2008 13:51:23 -0500, Alex Paschal <apaschal AT MSIINET DOT 
>> COM> said:


> Something like readline used for the command line client, so we
> could get vi-style-editing (ok, fine, or emacs for the heathens) &
> history search/recall/edit.

Yeah that.

>  "edit cancelprocs" spawns vi/emacs/nano/whatever, then "run
> cancelprocs" to execute.  "define script cancelprocs type=external
> path=/dir/cancelprocs" maybe.


This leads to your TSM servers being delicate unique flowers.  Ick.
Prefer, instead, to edit your scripts outside of TSM, and then load
them automatically; def scr foo file=/dev/foo.

Being an overengineer, I've got a script 'reload-scripts', which

- Defines, runs and then deletes an autogenerated script which deletes
  all my other autogenerated scripts

- Defines and runs an autogenerated script which defines all my other
  autogenerated scripts.

This means that all of my auto-generated scripts in the running
servers are shadows of the on-disk versions.


> Add the ability to track file/filetree moves and update hl_name
> rather than expire and rebackup in new location.

I think you don't want this.  I understand why you think you want it,
but I really really think you don't.

EG:

 Joe's been working in /home/joe/Projects/yadda for years,
 irregularly.  One of those twice-a-year thingies.  One year he gets a
 wild hair and moves it to
 /home/joe/obscure/heirarchy/that/made/sense/at/the/time/yadda.  Come
 on, you know you've done it.

 TSM reorganizes a filesystem-like structure inside itself to note the
 directory move; it changes the hl_names on all the extant data, whee,
 we're done.

 Now it's forgotten that the old path ever existed.  If you restore to
 a month ago, you'll get the new heirarchy, but with the internal
 state accurate for a month ago's old heirarchy.

 You'll be rewriting history.  And God help you if joe forgets what he
 did with it, comes back 65 days later (knowing retonly to be 120
 days) and says 'Dang, why does dsmc q backup /home/joe/Projects/yadda
 say "no data" ?  I've been using that for years!'.


Sufficiently smart de-dupe type behavior could save re-sending all the
bytes, which would be keen: Deactivate the existing objects, and
create new active ones with the new hl_name, perhaps, pointing at the
same blob.  But I think you really want a new object entry describing
the new name.


- Allen S. Rout