>> On Tue, 6 May 2008 13:51:23 -0500, Alex Paschal <[EMAIL PROTECTED]> 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
