Bug 66 - Wrong volume informations saved when creating or editing a volume.
Summary: Wrong volume informations saved when creating or editing a volume.
Status: RESOLVED FIXED
Alias: None
Product: ZeXtras
Classification: Unclassified
Component: ZxPowerStore (show other bugs)
Version: 1.8.2
Hardware: -- Linux
: Normal critical
Assignee: ZeXtras Bugzilla Admin
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2013-03-15 09:04 CET by Cine
Modified: 2013-03-15 13:47 CET (History)
0 users

See Also:
Browser: ---
Zimlet Chat version: ---
Zimbra Version: 7.0.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Cine 2013-03-15 09:04:51 CET
====Bug description:====
This bug caused the ZeXtras Powerstore module to arbitrarily set the "file_bits", "file_group_bits", "mailbox_bits" and "mailbox_group_bits" volume properties to "0", overwriting any existing previous values, when a volume is created or edited.
Since this values are used by Zimbra to define the path on which BLOB files are saved, there is a chance that files in affected volumes will be saved on a different path than expected (see the "Effects" section below for more information).


====Who's affected:====
The bug affects ZeXtras Suite versions from 1.4.0 to 1.8.2 running on Zimbra 8.x servers (Zimbra 7.x servers are not affected). Creating or editing a volume through either the ZeXtras CLI or the ZeXtras Administration Zimlet will trigger the bug, causing wrong informations to be written in the Zimbra database.
If you are running an affected ZeXtras Suite version, you can check if any of your store is affected by simply entering the mysql CLI in your Zimbra server (running the `mysql` command as the zimbra user) and run the following query:
  
  select * from zimbra.volume;

Affected volumes are those for which the "file_bits", "file_group_bits", "mailbox_bits" and "mailbox_group_bits" properties are wrongly set to "0" - if you manually set those values to "0" then the volume is not to be considered affected by the effects of this bug.
 
If you are running ZeXtras Suite 1.8.3+, see the "Response and Fix" section below to find how to use the "doFixVolumes" command to check and fix the status of your volumes.

If you find that one or more volumes are affected, but your ZeXtras Suite License/Trial is expired, please install ZeXtras Suite 1.8.3 or higher. The "doFixVolume" CLI command (see below) does not require an active license to be functional.


====Effects:====
Different scenarios apply

- If a pre-existing volume has been edited by an affected ZeXtras Suite version there is a chance that items created prior to the edit, albeit being on the filesystem, will not be accessible by Zimbra. 
When an user tried to access one of those BLOBS, a "No such BLOB error" will be displayed in the Zimbra Web Client and in the /opt/zimbra/log/mailbox.log file. This only applies to items with an id lower than 4096.

- If ZeXtras Suite 1.8.2 has been installed and a volume affected by the bug has been edited, there a chance for items with an id higher than 4096 to not be accessible by Zimbra.    


====Response and fix:====
Versions of ZeXtras Suite from 1.8.2 onwards are unaffected by this bug, but an action is required to fix any previously affected volumes. All ZeXtras Suite versions starting from 1.8.3 include a CLI command to check and fix all affected volumes: 

zxsuite powerstore doFixVolumes

This command can be used to both check the status of your volumes and to fix those volumes affected by the bug.

To check your volumes, run 

  `zxsuite powerstore diFixVolumes check`

The script will check all message volumes and will report any volume that might be affected by the bug.

If one or more volumes are reported by the check command, you can run 

  `zxsuite powerstore diFixVolumes start_fix` 

to start the fix. 
This will set the correct "file_bits", "file_group_bits", "mailbox_bits" and "mailbox_group_bits" for the affected volumes, check for out-of-place BLOB files and move all of this files to the proper folder.
The --progress switch is forced on this command, you can safely interrupt the output display by pressing CTRL+C. The operation itself will not be affected.
Comment 1 Cine 2013-03-15 13:47:41 CET
Many thanks to our partner Silvan of Openfactory Gmbh for reporting the issue and for his great goodwill in supporting us in the analysis of such.

Cine