Skarvia says the name is already taken. What does that mean?

A file already sits at that path in your Dropbox or Google Drive, and a different document wrote it. Skarvia will neither load that file into this document nor overwrite it, so nothing has been lost on either side. Open the storage button in the status bar, give this document a different name or folder, and press Save here. It syncs on the next save. The usual cause is two documents that were both called Untitled when they first saved.

My storage chip says reconnect. Have I lost work?

No. That state means your writing is reaching Skarvia and is not reaching your cloud provider, because the connection has lapsed or been revoked. Keep writing. Click Reconnect in the bar at the top of the editor, sign in again, and the next save pushes everything that accumulated while the connection was down.

Where does a conflict backup go?

Into Versions, named conflict backup followed by the date and time. Skarvia writes one when it is about to adopt a newer cloud copy of a document you also have unsynced edits on, so both texts survive and you choose between them. Zero-retention documents are the exception: that snapshot is deliberately skipped, because writing the whole manuscript into a new row is exactly what the setting exists to prevent.

Chapter 8 · Where Your Work Lives

When Sync Goes Wrong

Sync fails for boring reasons: a token expires, a laptop loses its network, two documents want the same filename. Skarvia's job at that moment is to tell you which of those it is, hold your work while it lasts, and never guess. This chapter is the field guide to every state you can see and what each one asks of you.

Two journeys, two indicators

Your words take two trips, and they fail independently. Knowing which one broke tells you how worried to be.

Your browser to Skarvia. The save indicator near the document title reports this one. When it reads Saved, the server has your text.
Skarvia to your storage. The chip at the right of the status bar reports this one, naming the provider and the path. This trip writes the real files described in Chapter 3.

A broken second leg is uncomfortable and recoverable, because Skarvia is still holding everything and will push the backlog the moment the connection returns. A broken first leg is the one to act on, and it announces itself loudly rather than hiding in a chip.

Cloud pushes are throttled to about one every ten seconds per document, and choosing a destination or restoring a version forces one immediately. After a save lands, Skarvia re-reads the storage record a few seconds later, so a push that failed behind a successful save still reaches your eyes.

Every state the chip can show

Chip	State	What it means
⚠ choose where this doc lives	No destination	You answered "Not now" on the first save. Your work is held and autosaved, with no file of its own anywhere.
… saving to	pending	A destination is set and the first successful write has not landed yet. Normal for a few seconds after you choose one.
✓ saved to	synced	The cloud copy matches. This is the resting state.
✗ retrying	error	The write was attempted and did not succeed. Skarvia keeps trying on later saves.
✗ reconnect	disconnected	There is no usable authorisation for the provider. Nothing will reach it until you sign in again.
⚠ name already taken in	occupied	A file written by a different document already occupies that path. Skarvia has touched neither side.
Saved on this computer …	local folder	The browser holds the folder, so the mark comes from the last write it attempted. See below.

The chip is a button, and clicking it reopens the storage dialog, which is where most of these states are resolved. On a local folder that is waiting for permission, the same click asks your browser for it instead.

Reconnect: the connection lapsed

When a provider has no working authorisation, a bar appears across the top of the editor saying that provider stopped saving your work, that your recent changes are safe on Skarvia, and that they are not reaching the provider until you reconnect. It carries two buttons: Reconnect, which restarts the authorisation handoff and returns you to this document, and Save somewhere else, which opens the storage dialog so you can point the document at a different provider or a local folder instead.

Google Drive reaches this state in one way that surprises people. Skarvia holds a drive.file permission, which reaches only the files Skarvia itself created, so if the credentials behind those files change, Drive refuses a perfectly ordinary edit. Skarvia tests the connection before deciding what to show, and says reconnect only when reconnecting is the fix. See Chapter 5.

Your Account page repeats the Google Drive warning under Connected storage, so a stale connection is visible even if you have not opened the document in a while.

Retrying: the write failed

The error state means the request went out and came back wrong: a provider outage, a rejected upload, a network that dropped mid-write. There is nothing to fix by hand, so keep writing and the next save retries. If it persists across a session, point the document at a second destination from the storage dialog. Files already written to the old location stay where they are.

The name is already taken

This one has a specific cause and a two-click fix. Every new document is created as Untitled, so if you make several before naming them, they propose the same cloud path. When a document that has never synced is pointed at a path where a .skarvia.json already exists, Skarvia stops.

Both alternatives are destructive, which is why it does neither. Adopting the file would pour another document's text and settings into this one, and overwriting it would destroy work that belongs to something else. The push is refused, and the chip's tooltip spells out that Skarvia has touched the file in neither direction.

The fix: open the storage button, give this document its own name or folder, and press Save here. The next save syncs normally. Naming a document before its first save avoids the situation entirely.

Folders on your own machine

Local folders are written by your browser, not by Skarvia's servers, so the chip reports what the browser last managed. Three things it can say:

A tick means the last write into your folder succeeded.
A cross means it failed, and the bar at the top of the editor asks you to choose a folder your browser will allow. Desktop, Documents, and Downloads are refused to every website; a dedicated folder inside one is fine.
Click to re-authorize means the folder permission did not survive the browser restart. One click, one browser prompt, and the pending text is written out.

Filename collisions look different here. Skarvia stamps each local .skarvia.json with the document that owns it and will not write over one belonging to another, which surfaces as the failed-write state rather than as its own status. Rename the document and it writes cleanly. Chapter 6 covers local folders in full.

Edited somewhere else, and conflict backups

Because the file is genuinely yours, it can change while Skarvia is not looking. On open, Skarvia compares the cloud copy against what it last wrote, and adopts the cloud copy if it has moved on. If you also have edits that never synced, those are preserved first as a version named conflict backup with the date and time, so both drafts survive and you pick the winner in Versions. Restoring one is itself non-destructive, as Chapter 7 explains.

A local folder asks instead of acting: if the file there is meaningfully newer, Skarvia asks whether to load the local copy, and answering no changes nothing.

Zero retention removes the conflict backup on purpose. That snapshot would write your entire manuscript into a new database row at the moment you were least likely to be watching, which is the thing the setting exists to prevent. On a zero-retention document, let the chip read synced before you edit the same text elsewhere.

Unsaved changes from this device

If a save never reaches the server, your browser keeps the text locally anyway, and two things follow from that.

While it is happening, a warning appears once two attempts in a row have failed, saying your work is safe on this device and has not reached the server, with a Try now button. Retries continue on their own, backing off from four seconds to a minute, so a brief outage resolves without you touching anything.

The next time you open the document, if that stored text still differs from the server's, a bar offers it back: when it was written, its word count against the server's, and a plain statement that it was never saved. Restore them saves it through the normal path and reloads; Discard throws it away. When both word counts match, the bar says so and tells you the difference is in formatting or production marks, which is the case worth reading twice before discarding.

What to do while it is broken

Keep writing. Every state on this page leaves at least one complete copy of your document somewhere, and most leave two. Sync catches up when the obstacle clears, and nothing is discarded quietly in the meantime.

If a state persists and the fix is not obvious, the ✎ Feedback button reaches the people building Skarvia. Quote the exact chip text and name the provider, which is usually enough to identify the problem without a screenshot. The status bar itself, and everything else it carries, is the subject of Part III.

Updated 2026-08-15 · Full contents · Something wrong or missing?

Start writing free