edde746
3f49bcabf8
Upstream shared_preferences_windows and _linux write the whole preference document with a bare `writeAsStringSync`. That opens with the default `FileMode.write`, which truncates the live file before writing it, so every single preference write has a window in which the only copy on disk is empty or half-written. A crash, power loss, forced reboot or antivirus interception inside that window leaves a document that fails to parse on every subsequent launch — and the store holds the credential-vault key, so the loss is not recoverable by rewriting it. This is the corruption class behind #1732; the recovery path already landed is a band-aid over it. Vendor both packages under packages/ — the convention saf_util and wakelock_plus already follow — and stage, flush, then rename over the target. The flush has to precede the rename or it could publish contents that were never committed, the same corruption by another route. Staging uses one fixed sibling name rather than a stamped one, because the file is a plaintext copy of the vault key, tracker refresh tokens and Seerr cookies; it is created in the target's own directory so rename stays on one volume and the mode matches what the canonical file would have had, and a stale one is swept once the canonical document has been read cleanly. Both deltas are marked in-source and in provenance.json with the refresh contract. Atomicity is proven, not asserted. A hard link to the store observes the old document after a write, which only holds when the directory entry was replaced — truncate-in-place would have rewritten the shared inode, and that test does fail against unpatched upstream. Upstream's own suites still pass unchanged in both packages and now run in CI, so the patch keeps the contract it inherited. Windows `MoveFileExW` replacement semantics cannot be proven on a POSIX runner or a memory file system, so they get their own test on the existing windows-latest job, including replacement while a reader holds the file open — antivirus and Search Indexer both do.
30 lines
1.1 KiB
Dart
30 lines
1.1 KiB
Dart
// Copyright 2013 The Flutter Authors. All rights reserved.
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
// found in the LICENSE file.
|
|
import 'package:flutter_test/flutter_test.dart';
|
|
import 'package:path_provider_linux/path_provider_linux.dart';
|
|
import 'package:path_provider_platform_interface/path_provider_platform_interface.dart';
|
|
|
|
/// Fake implementation of PathProviderLinux that returns hard-coded paths,
|
|
/// allowing tests to run on any platform.
|
|
///
|
|
/// Note that this should only be used with an in-memory filesystem, as the
|
|
/// path it returns is a root path that does not actually exist on Linux.
|
|
class FakePathProviderLinux extends PathProviderPlatform
|
|
implements PathProviderLinux {
|
|
@override
|
|
Future<String?> getApplicationSupportPath() async => r'/appsupport';
|
|
|
|
@override
|
|
Future<String?> getTemporaryPath() async => null;
|
|
|
|
@override
|
|
Future<String?> getLibraryPath() async => null;
|
|
|
|
@override
|
|
Future<String?> getApplicationDocumentsPath() async => null;
|
|
|
|
@override
|
|
Future<String?> getDownloadsPath() async => null;
|
|
}
|