One of the changes in build 9756 was to improve how messages on an unreachable secondary storage are handled. Specifically, any potentially damaging actions involving secondary messages - auto deleting, moving an item to secondary storage, disabling secondary storage, etc. - are avoided when the secondary path is unreachable. If your secondary storage goes offline, all that should happen is that the message or file storage item cannot be accessed. This means that rebuilding folders after a secondary storage outage should no longer be necessary and information like flags, read state, and more should be maintained until the secondary store is restored.

Great.

I'll run some tests, then.

Could you clarify that a bit, though?

You mentioned "unreachable," implying the path doesn't exist.

But if the path *does* exist yet is empty, how does it behave?

By "unreachable," I meant that the secondary storage path defined in the domain settings isn't currently accessible. On Linux, that path is typically a mount point: a regular directory that the storage device is mounted onto. When the device isn't mounted, the directory still exists, but it's just an empty folder on the underlying (usually root) filesystem. Because of that, SmarterMail runs several checks to determine whether it's looking at the mounted device or just the bare mount point. Once a secondary storage path has been identified as reachable, SmarterMail has no way of knowing that a restore is in progress, so it acts as if the data it finds is complete and allows potentially destructive actions to proceed.

For the recovery scenario you described, I recommend keeping the replacement drive disconnected from your SmarterMail server until you've finished restoring data to it. This keeps the secondary path unreachable, so SmarterMail won't act on the items it expects to exist there until you reconnect the drive with the restore complete.

Ohhh that means the email index wont go missing after it come back online right?

Looks like i should upgrade soon to benefit from this improvement

Update.

I’ve run some tests.

Windows environment.

I enabled the secondary path on a domain.

Then, I simply renamed the secondary path folder on the disk.

I waited three days; in the meantime, I even attempted re-indexing.

The messages remained inaccessible and were not removed from the index.

As soon as I restored the original folder name, the messages became accessible again.

Great work.

To me, this is exactly how it should work.

The system didn't determine whether it was an external mount; it simply failed to find the folder and took no action.

The only question remaining for me is:

If I, as the administrator, decide that the path will not be restored, how do I tell SM to delete the messages from the index?

Right now, the only way to tell SmarterMail to clean up the messages that won't be restored is:

With those settings removed, secondary storage for the domain will be fully disabled. When SmarterMail does a clean after that, messages marked as being in secondary storage will be treated as missing and will be removed from the account's CFG files and index.