Anonymous_User Absent Member.
Absent Member.
3750 views

6000 Orphaned blob files

Results of a Contents check (finally decided to looka t the log, think
this runs weekly)
over 6000 Orphaned blob files. It says (deleted) but the actual blobl
files look like they're still there. so not sure what the 'deleted'
refers to..

Anyway, what should I do here? Anyway to clean the blobs up?

Processing information for this run:
Path to PO = email/email:\asbpo
Post Office= asbpo
User = All
Action = Analyze/Fix
Files = Message, User, Document
Verify = Structure/Contents
Fixup num = All

Uncorrectable conditions encountered:
CODE DESCRIPTION COUNT
---- -------------------------------------------------- -----
50 Orphaned Blob files (deleted)...................... 6323
83 Items that have failed to archive.................. 44

Example of error in GWcheck log:
Checking Blob files for validity
- checking area storage\dms2:\actcllb
- Checking directory FD0
- Blob is a document file
- Library ID: ASBDOM.asbpo.Active clients
- Document Num: 191530
- Version Num: 1
- Document Subject:
$(B‘r“s?‹V$(Cکĵ?ÍóÒ¦?$(B⎁¥ƒ`âŽ?Ÿ…ï`‚‘“pmŠspƒ`ï“í`‚㄁‚‚†‹•$(CÄ
³f
- Author Name: Rachel Judkins
- Author DPU: asbdom.asbpo.rjudkins
- File Extension: pdf
Error 50- Orphaned Blob file: 3FEFE5D4.000
Return from WpioDirCreate = 0x8209
- Blob is a document file
- Library ID: ASBDOM.asbpo.Active clients
- Document Num: 97838
- Version Num: 1
- Document Subject:
$(B”ry?$(CáâÆ®ëà$(Bž`$(C¾¯?$(B⎁¥‚`âŽ?µç`Œ¡?$(C½éÔ§î¨Ù³ò²ö»óÉýÌÄ
³f
- Author Name: Tamer Shatara
- Author DPU: asbdom.asbpo.tshatara
- File Extension: pdf
Error 50- Orphaned Blob file: 3FF1CDEF.000
Return from WpioDirCreate = 0x8209
--

Labels (1)
0 Likes
10 Replies
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Joe Brugaletta wrote:

> It says (deleted) but the actual blobl files look like they're still
> there. so not sure what the 'deleted' refers to..


> - checking area storage\dms2:\actcllb


This is, alas, pretty much a known issue that if you have your storage
location directly off the root of the volume (i.e. dms2:\actcllb rather than
dms2:\docs\actcllb) GWCheck will never really delete the blobs.

I'd suggest you move the storage location to one spot deeper.
--
Danita Zanre
Novell Support Forums Volunteer
GroupWise 7 Upgrade Guide!
www.caledonia.net/gw7upg.html
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

ugh.. how long has this been known? 😕
good catch, Danita. pain to move this?
--



Danita Zanre wrote:

> Joe Brugaletta wrote:
>
> > It says (deleted) but the actual blobl files look like they're still
> > there. so not sure what the 'deleted' refers to..

>
> > - checking area storage\dms2:\actcllb

>
> This is, alas, pretty much a known issue that if you have your storage
> location directly off the root of the volume (i.e. dms2:\actcllb
> rather than dms2:\docs\actcllb) GWCheck will never really delete the
> blobs.
>
> I'd suggest you move the storage location to one spot deeper.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Joe Brugaletta wrote:

> ugh.. how long has this been known?


Pretty much as long as I've done DMS <sigh> - I thought there was a TID on
it, but I can't put my finger on it right now. Dave and I have mentioned
every chance we get to put together a DMS presentation, and it's documented
in my DMS book of course!

> pain to move this?


Not really. Here's a little excerpt that will show you how - this talks
about physically moving it from one server to another. If you use FILER for
NetWare the "move" will take seconds, rather than hours 🙂

Moving a Document Management Storage Area
You just out grew your server storage, now what? Guess its time to move, or
in this case move the DMS storage area. Contrary to popular belief document
storage areas can be moved, and it is not difficult, nor is it a “train
wreck” waiting to happen. In this section, we will walk you thru
the process.
1 Test that the current old storage area and the library attached to it are
working correctly
2 Create a document. Then check its Log file to see if it is in the correct
storage area.
3 Disable Post Office logins. This insures exclusive access to the post
office and library during the move.
4 Unload the POA
5 Move the storage area to the new server (Joe - here's where you would just
use FILER to move the pointer).
6 Run ConsoleOne
7 Select the Library involved in the storage move
8 Right click and select Properties
9 Select the Storage Area page of the Library
10 Select the Storage Area moved
11 Click the Edit button
12 Change the UNC path on the Edit the Document Storage Area page
13 Select OK
14 Select Apply
15 Select OK, to close the Library Properties window
16 Verify the change took effect. Close ConsoleOne, then load ConsoleOne
again and view the properties of the Library and its Storage Area. This is
an extra step that you might feel is not be warranted, but is well worth the
time for peace of mind.
17 Load the POA with the /user- , /password- (if necessary), /ll-verbose and
/noconfig- switches. This will give the changes made a chance to propagate
out and force the log level to verbose.
After about 10 minutes all changes should have been communicated.
18 View the POA log file for a reference to the change being made. Enable
login for the Post Office in ConsoleOne
19 Unload the POA and reload it with its regular startup file. In some cases
the POA may startup with a DF17, F107, or F103 which means it can't access
the remote storage area of the documents. So if you followed the step above
and are still getting the DF17 you will need to continue using the
/NOCONFIG, /USER, /PASSWORD switches.
20 Test the new storage area by opening up the document you created at the
beginning of this procedure, view its contents, then close it. Then go to
the Log file for the document and see if the new storage location is noted
in the filename.
21 Finally, create a new document in the library, then view its log file to
verify it was saved into the new storage area.

--
Danita Zanre
Novell Support Forums Volunteer
GroupWise 7 Upgrade Guide!
www.caledonia.net/gw7upg.html
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Thanks Danita!
i'll mess around on a test library first 🙂
So all of the old files will reference the new location without having
to be indexed or anything?
--



Danita Zanre wrote:

> > pain to move this?

>
> Not really. Here's a little excerpt that will show you how - this
> talks about physically moving it from one server to another. If you
> use FILER for NetWare the "move" will take seconds, rather than hours
> 🙂
>
> Moving a Document Management Storage Area
> You just out grew your server storage, now what? Guess its time to
> move, or in this case move the DMS storage area. Contrary to popular
> belief document storage areas can be moved, and it is not difficult,
> nor is it a “train wreck” waiting to happen. In this section, we
> will walk you thru the process.
> 1 Test that the current old storage area and the library attached to
> it are working correctly
> 2 Create a document. Then check its Log file to see if it is in the
> correct storage area.
> 3 Disable Post Office logins. This insures exclusive access to the
> post office and library during the move.
> 4 Unload the POA
> 5 Move the storage area to the new server (Joe - here's where you
> would just use FILER to move the pointer).
> 6 Run ConsoleOne
> 7 Select the Library involved in the storage move
> 8 Right click and select Properties
> 9 Select the Storage Area page of the Library
> 10 Select the Storage Area moved
> 11 Click the Edit button
> 12 Change the UNC path on the Edit the Document Storage Area page
> 13 Select OK
> 14 Select Apply
> 15 Select OK, to close the Library Properties window
> 16 Verify the change took effect. Close ConsoleOne, then load
> ConsoleOne again and view the properties of the Library and its
> Storage Area. This is an extra step that you might feel is not be
> warranted, but is well worth the time for peace of mind.
> 17 Load the POA with the /user- , /password- (if necessary),
> /ll-verbose and /noconfig- switches. This will give the changes made
> a chance to propagate out and force the log level to verbose.
> After about 10 minutes all changes should have been communicated.
> 18 View the POA log file for a reference to the change being made.
> Enable login for the Post Office in ConsoleOne
> 19 Unload the POA and reload it with its regular startup file. In
> some cases the POA may startup with a DF17, F107, or F103 which means
> it can't access the remote storage area of the documents. So if you
> followed the step above and are still getting the DF17 you will need
> to continue using the /NOCONFIG, /USER, /PASSWORD switches.
> 20 Test the new storage area by opening up the document you created
> at the beginning of this procedure, view its contents, then close it.
> Then go to the Log file for the document and see if the new storage
> location is noted in the filename.
> 21 Finally, create a new document in the library, then view its log
> file to verify it was saved into the new storage area.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

To take this a step further..
there are still a lot of documents in the Active Client library that
are still stored at the Post Office. when we started running low on
space, we changed the storage area and now anything that is newly
created, or existing items that are opened/closed get sent to the
Storage/dms2: server. How does the 'move' instructions determine what
docs need its pointer changed and differentiate between the stuff that
is stored at the PO? Hope that makes some kind of sense.
--



Joe Brugaletta wrote:

> Thanks Danita!
> i'll mess around on a test library first 🙂
> So all of the old files will reference the new location without having
> to be indexed or anything?

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Joe Brugaletta wrote:

> So all of the old files will reference the new location without having to
> be indexed or anything?


Just happens.

--
Danita Zanre
Novell Support Forums Volunteer
GroupWise 7 Upgrade Guide!
www.caledonia.net/gw7upg.html
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Joe Brugaletta wrote:

> How does the 'move' instructions determine what docs need its pointer
> changed and differentiate between the stuff that is stored at the PO?


Doesn't matter. The ones under the PO just stay there - the pointers just
automagically work - no problem.

--
Danita Zanre
Novell Support Forums Volunteer
GroupWise 7 Upgrade Guide!
www.caledonia.net/gw7upg.html
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

My boss will be happy with that answer 😛
--



Danita Zanre wrote:

> Joe Brugaletta wrote:
>
> > So all of the old files will reference the new location without
> > having to be indexed or anything?

>
> Just happens.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Hi Joe,

Sorry to hear about you problem. Alex came into my office this morning asking me about the orphan document blobs at the root of the volume problem. I've never heard about it before. I guess somewhere along the support chain this info got filtered out.

Alex and I just got finished trying it with the standalone GWCheck in the debugger. Everything worked as we would expect. Each of the blobs were examined. In my test none of them were deleted because I had just imported them and we won't delete a file if it is less than 14 days old. However it entered the deletion code and detected the file timestamp issue and refused to delete. So we need to look into this more to find out why they aren't getting deleted in a normal system. (not a test system).

When you delete a storage area we look through all the document records. Any of the blobs that are stored in the area being deleted we create a new blob in any of the active storage areas and then we delete the old blob. That's how we know which blobs need to be moved and the links are updated correctly. That's why it "just works". It is a somewhat time consuming process because we have to examine all the doc records to determine what needs to move.

I hope this helps.

Good Luck,

Tony
P.S. I think Alex will continue investigating the storage area a the root problem.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: 6000 Orphaned blob files

Thanks for the response/explanation, Tony. I will play around with
this on a test library before moving the big guys.

Re: the GWCheck bug, let Alex know if he needs any other info from me
(or danita) regarding the problem.
--



Tony Caras wrote:

> Hi Joe,
>
> Sorry to hear about you problem. Alex came into my office this
> morning asking me about the orphan document blobs at the root of the
> volume problem. I've never heard about it before. I guess somewhere
> along the support chain this info got filtered out.
>
> Alex and I just got finished trying it with the standalone GWCheck in
> the debugger. Everything worked as we would expect. Each of the
> blobs were examined. In my test none of them were deleted because I
> had just imported them and we won't delete a file if it is less than
> 14 days old. However it entered the deletion code and detected the
> file timestamp issue and refused to delete. So we need to look into
> this more to find out why they aren't getting deleted in a normal
> system. (not a test system).
>
> When you delete a storage area we look through all the document
> records. Any of the blobs that are stored in the area being deleted
> we create a new blob in any of the active storage areas and then we
> delete the old blob. That's how we know which blobs need to be moved
> and the links are updated correctly. That's why it "just works". It
> is a somewhat time consuming process because we have to examine all
> the doc records to determine what needs to move.
>
> I hope this helps.
>
> Good Luck,
>
> Tony
> P.S. I think Alex will continue investigating the storage area a the
> root problem.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.