| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 379.1 | suggestion. go to V4.2B | DECWET::EVANS | Be a Point Of Light! | Tue Feb 04 1997 11:39 | 14 |
| Is this patch applied for NSR 4.2a?
>>>> yes.
Is there any workaround?
>>>> upgrade to V4.2B
Is there any incompatibilities between indexes created with 3.0 and how 4.2a
recreates them?
>>>> no, but an index conversion (one-way) takes place between V3.x and
>>>> V4.x, and there is a KNOWN BUG in V4.2A affecting idnexes, fixed in V4.2B
>>>> save yourself some headcahes, and upgrade now.
|
| 379.2 | tapes created by 4.2a give the same problem | STKHLM::BEETS | | Wed Feb 05 1997 02:37 | 10 |
| Thanks for your reply,
We will upgrade to 4.2b. We got the same problem with tapes created with 4.2a,
then client was deleted, added client again and then used scanner to recreate
the index.
Gunnar
|
| 379.3 | dang -- wish I'd done better research | DECWET::EVANS | Be a Point Of Light! | Wed Feb 05 1997 09:52 | 19 |
| I thought I was too busy... now I'm paying the price.
I went throught the code in NSR V3.x (we called it MAGPIE) and found the
patch I developed for this problem - it turns out, there are no comments,
but I recall it needed to be done because the buffer being used
got zeroed after calling AdvFS API to set the file attributes, and then it
tried to use that same buffer again for inheritable directory attributes.
Sadly, at that point, it was zero'ed, so gave an error, and the file recover
stream is swallowed leaving a file header with no data - a zero length file.
This code is not in V4.2x (a or b), nor is it in V.future - I will alert
the folks that make patches, and go about insuring this gets into V.future
stay tuned to the patch topic. Please thank your customer for upgrading to
V4.2B!!
I sincerely apologize for any inconvenience my previous note may have caused.
Bruce Evans
|
| 379.4 | that's why...... :-> | STKHLM::BEETS | | Fri Feb 07 1997 06:56 | 15 |
| Bruce,
Well, my customer upgraded to 4.2b and of course he still had problem. :-)
All clients created under 4.2x works fine. Only clients from 3.0 have this
problem. It makes sense.
I will stay tuned on patch topic for a patch. I suppose there's no need for any
QAR or IPMT then.
Thanks
Gunnar Beets
|
| 379.5 | early next week, we'll have the patch ready for you | DECWET::EVANS | Be a Point Of Light! | Fri Feb 07 1997 17:01 | 7 |
| I've just finally been able to apply the fix to the source tree
and checked it out to my limits.
We'll need your customer to see if it really fixes it when they
apply the patch, and do the recover.
Bruce
|
| 379.6 | I'll wait....... | STKHLM::BEETS | | Mon Feb 10 1997 02:39 | 5 |
| Update this note or send a mail where I can get the patch. I will be away on
Thursday(13th) and Friday(14th).
Gunnar
|
| 379.7 | | DECWET::RANDALL | | Thu Feb 20 1997 16:08 | 3 |
| The patch is now available. See Notes 53.12 and 53.13.
-- Rich Randall
|
| 379.8 | Still getting zero byte files with Patch12 | OTOOA::kap901.kao.dec.com::trimble | | Mon Apr 07 1997 14:04 | 10 |
| I installed the patch12 on my DUnix 4.0 client that was running 3.2A
and it still recovered the files as zero bytes...
Talk about frustrating, downloading a 22 Meg TAR to patch a couple of files...
And it still doesn't work.
Regards,
Jason
|
| 379.9 | | DECWET::RANDALL | | Tue Apr 08 1997 15:37 | 7 |
|
Hi,
Were the clients who are having the problem running V4.0 or later versions
of DIGITAL UNIX while they were running V3.0 of Networker?
-- Rich Randall
|
| 379.10 | Here's the scoop | OTOOA::kap901.kao.dec.com::trimble | | Wed Apr 09 1997 14:10 | 18 |
| Here is the situation:
NT 3.51 Alpha 2100A server running 4.3 of Networker
Alpha 2100A running OSF 3.2C and Networker client 3.2B
The OSF system was upgraded to 4.0 and I tried doing a
restore using the 3.2B NSR client. Zero block files.
Upgraded to 4.2B of client and tried restore. Zero byte
files.
Applied latest patch (12) and tried restore. Zero byte
files.
Any patches needed for DUnix 4.0?
Thanks,
Jason
|
| 379.11 | | DECWET::FARLEE | Insufficient Virtual um...er.... | Wed Apr 09 1997 15:37 | 9 |
| I'm afraid that the bad news is that if the backups were done using
DU 4.0 or above, with a version of NetWorker prior to 3.2A of NetWorker,
the data is simply not on tape correctly.
Your best bet is to try to restore a backup which was taken before
the upgrade to DU4.0 , using the 3.2B (or better yet, 4.2B) NetWorker client
software.
Kevin
|
| 379.12 | Not good... | OTOOA::kap901.kao.dec.com::trimble | | Thu Apr 10 1997 06:48 | 4 |
| You've got to be kidding me... This is not good.
Jason
|
| 379.13 | this is FAR too serious to be kidding anyone, Jason. | DECWET::EVANS | NSR Engineering | Fri Apr 11 1997 15:38 | 10 |
| Believe me... we understand what is happening in your mind right now.
we've gone through it.
Do the right thing, and get the data backed up and CHECK IT so you can
sleep easy. Do random browses, and check sizes of files in the GUI.
Also, do random recovers (using relocate), and sum/diff/whatever the
saved file with the recovered-relocated file.
Do this for UFS, AdvFS, and (if there) raw partitions. Be aggressive, not
passive, in your data protection mechanisms.
|
| 379.14 | Time is a scarce | OTOOA::kap901.kao.dec.com::trimble | | Tue Apr 15 1997 06:48 | 14 |
| Thanks for the tips. Unfortunately I am not a full time backup person. I
installed it, but I don't have the time to go into these details all the time.
It would take a person full time to check all of the systems we have
backing up to Networker now. We can't afford that kind of resource. Maybe
in the future this will change. Right now I have upgraded the system and
done full backups and tried a restore of one file to make sure it restored
fine and it did. So I am resting a bit easier now (as is the customer).
I have other problems now which require a new note.
Regards,
Jason
|