(src/serviceModules/FileSystemAdapters/pathAliasGuard.ts)
- Require every existing, unindexed path component to use a name listed by its parent directory.
- Accept case-only and Unicode-normalisation differences while caching positive directory listings briefly.
(src/serviceModules/FileSystemAdapters/ObsidianStorageAdapter.ts, src/serviceModules/FileSystemAdapters/ObsidianVaultAdapter.ts)
- Apply the alias boundary before text, binary, append, directory, removal, create, modify, rename, delete, and trash operations.
- Check both the source and destination of vault renames before calling the host API.
(src/serviceModules/FileSystemAdapters/pathAliasGuard.unit.spec.ts)
- Cover directory and file aliases across every mutating adapter route with synthetic host behaviour.
- Exercise real host filesystem aliases where the platform exposes them, including new files and directories below an aliased folder.
- Preserve listed names, case-only differences, indexed paths, and new-file behaviour.
(src/serviceModules/FileSystemAdapters/ObsidianStorageAdapter.unit.spec.ts, src/serviceModules/FileSystemAdapters/ObsidianVaultAdapter.unit.spec.ts)
- Extend existing adapter fixtures with the vault-index contract used by the guard.
Use the packaged Commonlib type import and add regression coverage for every Obsidian vault and storage write method. Verify that fractional timestamps are floored without mutating caller-owned options.
Obsidian's mobile storage layer forwards mtime/ctime to Capacitor's
Filesystem.setTimes, whose native binding casts the value to a Java Long.
A non-integer (float) timestamp makes that cast throw (ClassCastException:
Double cannot be cast to Long), which crashes the app on launch as soon as
such a document is replicated in.
Float timestamps can reach the database from any client that stores
fs.Stats.mtimeMs without flooring. Coerce mtime/ctime to integer ms at the
Obsidian vault and storage adapter write boundary, so a float already
present in the mesh can't crash the app regardless of where it came from.
The truly central choke point is dbToStorage in livesync-commonlib; a
matching guard there would cover the CLI and webapp too. This change
protects the platform that actually crashes.
Claude-Session: https://claude.ai/code/session_0123E9jVQrsgu3zb82Csuwhi
Now, Self-hosted LiveSync has finally begun to be split into the Self-hosted LiveSync plugin for Obsidian, and a properly abstracted version of it.
This may not offer much benefit to Obsidian plugin users, or might even cause a slight inconvenience, but I believe it will certainly help improve testability and make the ecosystem better.
However, I do not see the point in putting something with little benefit into beta, so I am handling this on the alpha branch. I would actually preferred to create an R&D branch, but I was not keen on the ampersand, and I feel it will eventually become a proper beta anyway.
### Refactored
- Separated `ObsidianLiveSyncPlugin` into `ObsidianLiveSyncPlugin` and `LiveSyncBaseCore`.
- Now `LiveSyncCore` indicates the type specified version of `LiveSyncBaseCore`.
- Referencing `plugin.xxx` has been rewritten to referencing the corresponding service or `core.xxx`.
### Internal API changes
- Storage Access APIs are now yielding Promises. This is to allow more limited storage platforms to be supported.
### R&D
- Browser-version of Self-hosted LiveSync is now in development. This is not intended for public use now, but I will eventually make it available for testing.
- We can see the code in `src/apps/webapp` for the browser version.
### Fixed
- Unlocking the remote database after rebuilding has been fixed.
### Refactored
- Now `StorageEventManagerBase` is separated from `StorageEventManagerObsidian` following their concerns.
- Now `FileAccessBase` is separated from `FileAccessObsidian` following their concerns.
Kim Jansheden