I'm growing more and more desprerate to resolve this.
What version of BSA are you using?
This is on windows?
This is fixed in 8.1 SP3 and 8.2. the fix was not backported to 8.0 from what I can tell.
What is the problem here though? the file is unzipped ok right?
Hah - look at the title of the posting :-)
Yes, very much on windows.
So this is an issue with this version of bladelogic?
The file is unzipped successfully, but then the job fails with errors like this all over the place:
Error Apr 26, 2012 11:07:33 AM warning: cannot set modification, access times for directory-name/server/delta/lib/
Error Apr 26, 2012 11:07:33 AM warning: set times/attribs failed for directory-name/server/delta/lib/
This really is a bladelogic bug or a "setup/permissions" issue?
It’s a defect in how we interact w/ some windows apis. In the job put an ‘exit 0’ after the unzip command and the job should exit w/o an error.
even if it's filled with "could not apply blah blah blah"?
Yeah – it’s just having problems apply permissions… so add a chmod or chown after the fact if you need to. but it’s windows so I don’t think that matters.
the bigger issue is - does exit 0 exit the entire job run?
For instance, this job will put a zip file on some machine, unpack it then apply some configuration (really standard stuffs).
I obviously can't have anything beyond the exit 0 in the nsh script - but will this exit skip anything/everything else I have in the aggregate job?
The unzip is happening in a blpackage, custom software or a nsh script ?
The I have an aggregate job that runs a package job and an nsh script job.
Can I have the unzip as part of the package?
You can have the unzip wherever you want.
Where is it now ?
To reiterate - I have an aggregate job - it has two parts, one deploys the bl package the other is an nsh script job (which cd's into where the package was deployed and unzips the files).
It'd be much nicer to have the unzip be more tightly coupled to the zip files in question so I wouldn't have to maintain the path in the nsh script.
Oh … so why not use the ‘external command’ in the package to do the unzip ?