You are viewing limited content. For full access, please sign in.

Question

Question

Resolving Volume - Database Inconsistencies

Search and Retrieval
Updated January 22, 2020
asked on January 21, 2020

Greetings to you all,

A customer is experiencing misplaced files in the volumes. Some documents inside the client do not display thumbnails, images, text, edocs, etc... After some research, we found that the path in these  document properties points to an empty volume with only a "Temp" folder in it. However, when we search for the name of the file in the physical volumes, we find that it exists in a number of logical volumes. We then copied a few of them and placed them in the path the client is expecting the document to be in. The image of the document appeared. Same as subsequent ones but cannot do it for over 100,000 files. 

Please find volume structure below:

Starts from 1. "LFREPO\CUSTOMER NAME\DEFAULT\DEFAULT000000 - DEFAULT000027"

Then continues rollover from 2. "LFREPO\DEFAULT\DEFAULT000028 - DEFAULT000044".

Images, thumbnails, text, etc of files from the first range of volumes appear OKAY in the document viewer but files from the second set of rollover volumes do not display any images, text, thumbnails, etc....

We also used the volume consistency checker and found inconsistencies but not sure how to resolve them.

Attached is an image of the log of one of the volume generated by the Volume Consistency Checker.

DEFAULT000039 - VOLCHECKLOG.PNG
missing file error.PNG
DEFAULT000039 - VOLCHECKLOG.PNG (16.39 KB)
Download
missing file error.PNG (37.02 KB)
Download
0 0

Replies

replied on January 22, 2020

Laserfiche volumes are not duplicate or backups of each other. File IDs (which are used for their names on disk) are unique within the volume. So file 00000001 in volume 1 can be an entirely different image than 00000001 in volume 2.

Copying a file from one volume to another does allow the clients to display an image, but it does not recover the original document. You will need to restore the missing volume from backup, it cannot be recovered from other Laserfiche volumes.

1 0
replied on January 21, 2020

Hi Joseph,

 

It's not exactly clear how the inconsistency happened. I'd like some more information to help understand the problem:

 

1. Screenshot of from the Administrator Console of the Volume properties for DEFAULT000000

2. Screenshot of from the Administrator Console of the Volume properties for DEFAULT000028

3. Show properties of an entry from the LF Client that lives in DEFAULT0000000 (Right click on a document, goto properties, click on the Document Tab as well as the Page Info Tab and take screenshots of those.)

4. Show properties of an entry from the LF Client that lives in DEFAULT0000028 as per point 3.

5. Create a brand new entry in the repository and repeat step 3 for that new entry.

 

Let's get a visual of what's happening with your shared screenshots of above and then take it from there.

0 0
replied on January 22, 2020
0 0
replied on January 22, 2020

Hi Joseph,

 

Based on the info provided, the database is reporting the following:

 

1. Browse to Windows path G:....\DEFAULT000000\e0\00\04\000004A4.PDF and confirm this file exists

2. Browse to Windows path G:....\DEFAULT000029\e0\00\06\00000666.PDF and confirm this file exists

3. Browse to Windows path G:....\DEFAULT000000\e0\00\01\000001E0.PDF and confirm this file exists

 

I am expecting that the file in path DEFAULT000000 doesn't exist since it was moved to another location. According to the database, it's supposed to be there as described above. You will then need to discover why/how it moved to another location and what that location is. Alternatively, if you do not know where it was moved to, you may need to compare and restore from backups.

Take note what Miruna is saying as well, you cannot just copy files between different numbered volumes. The file names might be the same but it's a unique file per volume and will not be the actual file you're looking for, it won't match the metadata for that entry.

 

What concerns me, is why the parent folder for DEFAULT000000 is different from DEFAULT000029. It tells me that the path was changed at some point. Although LF handles a path change quite easily for existing volumes, it's unclear if the path was only changed for newly created volumes or if it was changed for existing volumes too. I would ask why and when the path was changed. Since all paths are on the G:\, I can't imagine a path change was made because of space on the HDD.  

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...