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

Question

Question

Read-Only Volume State not a True "Read Only" State !

asked on April 3, 2014

Looking at best practices for doing backups of LF repos. the document mentions putting volume into "read-only" state, i tried it by just using the Admin console set a volume to read only state.

 

It worked great for "documents/files" however the gotcha was I could remove/rename/add new folders in the repository. So, the "read-only" state is not a true read only state, is this a known bug in LF 9.0 and has this been addressed in 9.1 version ?

 

 

I do not know how the back-end code works but I can see a problem when doing backups assuming no change to the Repository is taking place but in fact that is not true, will it put my backups in corrupt state if someone renames a folder while backup is being performed on a "read-only" volume ?

0 0

Answer

APPROVED ANSWER
replied on April 3, 2014

Fundamentally it is because those are not in a read-only state, as they are not part of the 'volumes'. The volumes are just the files, they are not the metadata.

 

The overview of the Laserfiche Server architecture in the administration guide may be a good reference to look at to familiarize yourself with the various components of the Laserfiche Server: http://www.laserfiche.com/support/webhelp/Laserfiche/9.1/en-US/AdminGuide/LFAdmin.htm#LaserFiche_Architecture_Overview.htm

2 0

Replies

replied on April 3, 2014

Folder structure, names and properties are all stored in the Laserfiche database. When you make a change to a folder no changes are made to the volume. The Volume only contains full page images and OCR data.

2 0
replied on April 3, 2014

That is correct, this works because updating folder structure is a Database change. However, the Volumes store e-docs and thumbnails in addition to full page images and OCR data.

0 0
replied on April 3, 2014

Page 2 of the Volumes: Introduction and Best Practices white paper outlines what kind of data is stored in Volumes.

1 0
replied on April 3, 2014

Oh yea and electronic documents, but thumbnails should be in the database under the thumbnails table. The client draws them in real time.

0 1
replied on April 3, 2014

The administration guide/help files provides a specific listing of exactly what is covered by this check box: http://www.laserfiche.com/support/webhelp/Laserfiche/9.1/en-US/AdminGuide/LFAdmin.htm#Read-Only_Volumes.htm.

 

One suggested practice for ensuring that the repository is read-only for backups (but still online) is to temporarily set the everyone group to 'Read-Only' in the administration console. No one will be able to make any changes unless they posses the 'Manage Trustees' privilege (needed to unset that option when you are done).

0 0
replied on April 3, 2014

I will have to go over that document again, it is such a different way one would not fathom. Folders/File renaming moving to different location in read-only state is a new concept for me.

0 0
APPROVED ANSWER
replied on April 3, 2014

Fundamentally it is because those are not in a read-only state, as they are not part of the 'volumes'. The volumes are just the files, they are not the metadata.

 

The overview of the Laserfiche Server architecture in the administration guide may be a good reference to look at to familiarize yourself with the various components of the Laserfiche Server: http://www.laserfiche.com/support/webhelp/Laserfiche/9.1/en-US/AdminGuide/LFAdmin.htm#LaserFiche_Architecture_Overview.htm

2 0
replied on April 3, 2014

I was going off this text in the white papers that does not talk about how "moving"/"renaming" process is handled on read-only volume. Hence the confusion.

 

"When a volume is read-only, its contents can be viewed but not modified. As with disabled volumes, files in read-only volumes cannot be modified and new files cannot be added to the volume. (Information that is not stored in the volume, such as templates, fields, and other metadata, can still be modified.)"

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

Sign in to reply to this post.