Can No Longer Update Cloud Storage

[besweeet]

Currently on 6.0.5705. Can't recall the previous version I was on but it's the first time updating in over a year. In any case, I cannot save to cloud storage.

My process has always been:

1. Open local XML file

2. Import new dives

3. Save local file

4. Save to cloud storage

This would always work. However, following the update, when going to the "Save to cloud storage" option, I get:

If I click "Replace cloud log," I get a red bar at the bottom of the window: "Cloud storage was not update. The current log remains open with its unsaved changes."

What next?

[Michael Keller]

Hi Besweeet.

On 19/9/26 04:53, besweeet wrote:
> Currently on 6.0.5705. Can't recall the previous version I was on but
> it's the first time updating in over a year. In any case, I cannot
> save to cloud storage.
>
> My process has always been:
> 1. Open local XML file
> 2. Import new dives
> 3. Save local file
> 4. Save to cloud storage

This is an odd way to use the cloud storage capability, and definitely
not how it was intended to be used when it was designed. The cloud log
is built around the concept of retaining history, so if it is used in
the intended way (opening the cloud log, adding dives, storing the cloud
log) it will only ever store the changes from the last time it was saved
(i.e. the new dives, or any changes that you made to existing dives).

The way you are using it you are essentially force-overwriting your
entire cloud storage every time you hit 'Save to cloud'.


It has been a regular occurrence that users managed to accidentally
overwrite their cloud log, and then had to open a support request to ask
the maintainers to restore their log from history. In order to reduce
this risk, and the work coming from it, the latest release of Subsurface
now includes the warning you are seeing.

> If I click "Replace cloud log," I get a red bar at the bottom of the
> window: "Cloud storage was not update. The current log remains open
> with its unsaved changes."

This looks like there is an error in the force-overwrite logic.


Can you please start Subsurface from the command line with `subsurface
-v -v -v', retry the operation, and then send us the log output?


Please also update to the current 6.0.5707 release first, as you are
currently on 6.0.5705:
https://subsurface-divelog.org/current-release/


Ngā mihi

  Michael Keller

[poe...@xs4all.nl]

Aha, i had the same notification - and workflow - as Besweeet!

Always open local file, edit or import dives, first save local and then save to the cloud so that I would have the same dives on my mobile.

And since the last release that is not allowed anymore.

I now adjusted my workflow: open the cloud, save and than 'save as' to local file.

I'm afraid if the cloud-version doesn't work anymore (or just not available) I will loose my dives so I start(ed) local (which is also backupped). Cloud is secondary..

Just to give insight in the userstory; I will adjust my workflow to whatever this great diving software want me to :-)

Op zaterdag 19 september 2026 om 03:48:23 UTC+2 schreef Michael Keller:

[Dirk Hohndel]

Cloud storage always has a local copy.
It is fully functional offline. Otherwise it would be useless garbage for a dive app, often used without connectivity.
It simply syncs history when connected again.
Your workflow destroys that history, the very feature implemented there and destroys any possibility to restore older versions of your data if you make a mistake and delete things you wanted to keep.
The new warnings simply make that explicit.

/D

[Douglas Stetner]

Thanks for the clarification Dirk.  I too tend to keep a local copy 'just in case'.  I am not sure if I followed Besweeet or poe's workflow in the past, but will now do the 'save as' route.  Is it possible to have a forth option for the 'Default dive log file' that is something like 'Use cloud storage and save back up file to local file'?

Thanks for a great app and all your hard work maintaining it.

Doug

[michael]

I too like to "Save as" an ssrf for backup. I've noticed that after
saving locally the next time I open subsurface it defaults to the local
file. If the designed workflow is to work with the cloud storage, then
after a "Save as" operation the program should maintain the cloud
connection.

Michael

> --
> You received this message because you are subscribed to the Google
> Groups "Subsurface Divelog" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to subsurface-dive...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/subsurface-divelog/3d794f9e-3c18-4978-a482-7b6defdd50c9n%40googlegroups.com
> .

[Dirk Hohndel]

I guess I fail to see the point of doing this.
Now you have two local copies and risk them getting out of sync.
One that keeps history (the local cache for the cloud), the other without (local XML file).

🤷

/D

[michael]

I do it so I have a backup that I control (it gets copied to my backup
disk and doesn't just stay local). If I "save as" locally every time I
update my log then everything is in sync. Since that's how I've always
done it, and subsurface starts with the "save as" log, I've never
really considered that there's another local copy. I've looked and have
not found the cache for the cloud. If I knew where that is it might
satisfy my backup desire.

Michael

On Sat, 2026-09-19 at 16:37 -0700, 'Dirk Hohndel' via Subsurface

> --
> You received this message because you are subscribed to the Google
> Groups "Subsurface Divelog" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to subsurface-dive...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/subsurface-divelog/67F096CF-ECDA-49C0-9B76-EE8C73AD1051%40hohndel.org
> .

[Robert Helling]

> On 20. Sep 2026, at 02:31, michael <mar4...@gmail.com> wrote:
>
> I do it so I have a backup that I control (it gets copied to my backup
> disk and doesn't just stay local). If I "save as" locally every time I
> update my log then everything is in sync. Since that's how I've always
> done it, and subsurface starts with the "save as" log, I've never
> really considered that there's another local copy. I've looked and have
> not found the cache for the cloud. If I knew where that is it might
> satisfy my backup desire.
>

I guess you are using Subsurface on Linux (based on the screenshot). You can run Subsurface from the command line with option -v and it will tell you where it keeps its local copy. Then you can include that in your backup. Just be careful, that is not a file but a directory and it appears empty as the actually information in is in subdirectories with names starting with a dot (it’s actually a git repository). Trust us, that is actually the better way to make sure your data is save, _as it contains past changes and can be rolled back_. I am specifically vague here (and some will think I have already been too specific) because if you start messing with those files manually there is a good chance that you actually mess up this repository in a non-recoverable way unless you really know what you are doing. But a lot of thought has gone into designing this to make your data maximally secure.

Hope that helps.

Robert

[Michael Keller]

Hi Michael.

On Sunday, September 20, 2026 at 9:55:57 AM UTC+12 mar4...@gmail.com wrote:

I too like to "Save as" an ssrf for backup. I've noticed that after
saving locally the next time I open subsurface it defaults to the local
file. If the designed workflow is to work with the cloud storage, then
after a "Save as" operation the program should maintain the cloud
connection.

One clarification: if Preferences → Dive log → “Cloud storage default file” is selected, Subsurface will open the cloud log on every normal application start. “Save As” creates and selects the local copy for the current session, but does not change that startup preference.

So a cloud-first workflow can be:

1. Open and work with the cloud log.
2. Save normally to commit the changes to cloud storage.
3. Use File → Save As to create a separate local backup when wanted.
4. On the next normal start, Subsurface will again open the cloud log, provided “Cloud storage default file” is still selected and Subsurface was not started with a file name on the command line.

The manual describes that setting as automatically loading the configured cloud dive log: https://subsurface-divelog.org/subsurface-user-manual/#_dive_log

If it instead opens the local backup after a restart, please check that preference is still set to “Cloud storage default file”.

Ngā mihi

  Michael Keller 

[michael]

Thanks Michael.

> --
> You received this message because you are subscribed to the Google
> Groups "Subsurface Divelog" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to subsurface-dive...@googlegroups.com.
> To view this discussion visit

> https://groups.google.com/d/msgid/subsurface-divelog/d68da355-d353-4dde-8e7b-737f843611f8n%40googlegroups.com
> .