OneDrive „Dateien bei Bedarf“ und Business-Apps — welche Annahmen Platzhalter zerbrechen und wie man damit umgeht

„Eine Business-App kann eine CSV nicht lesen, die ich auf dem Desktop gespeichert habe.“ „Ein Import, der funktionierte, scheitert nach einem PC-Tausch mit ‚Datei nicht gefunden‘.“ „Der Explorer zeigt die Datei, aber das Öffnen aus der App fehler.“ — In den letzten Jahren ist diese Art Kundenanfrage zum Standard geworden.

Untersucht man, ist die Ursache oft kein App-Bug, sondern OneDrives „automatische Sicherung von Desktop und Dokumente“ (Known Folder Move, KFM) und „Dateien bei Bedarf“. Der echte Desktop liegt unter C:\Users\<Name>\OneDrive\Desktop, und ein Teil der Dateien, die man dort sieht, sind „Platzhalter“ ohne lokalen Inhalt. Anwender und IT nutzen den PC weiter, ohne diese Änderung zu bemerken.

Mit anderen Worten: Die implizite Annahme einer Business-App, „die Datei liegt auf der lokalen Platte“, ist, ohne dass jemand das entschieden hat, durch die Annahme ersetzt worden, „die Datei ist in der Cloud, und lokal gibt es nur den Schein“. Zielgruppe sind IT-Verantwortliche in kleinen und mittleren Unternehmen sowie Windows-App-Entwickler. Der Artikel ordnet aus Microsoft-Learn-Primärquellen, wie Platzhalter funktionieren, wie man den Zustand aus Dateiattributen beurteilt, welche typischen Fallen eine Business-App tritt, was Entwicklungs- und IT-Seite tun können, und ein Triage-Verfahren, wenn man gefragt wird „die Datei öffnet sich nicht“.

flowchart TB
    accTitle: Ersetzung der impliziten Annahme einer Business-App
    accDescr: Die implizite Annahme einer Business-App, die Datei liege auf der lokalen Platte, ist ohne Entscheidung durch die Annahme ersetzt worden, der echte Inhalt sei in der Cloud und lokal gebe es nur den Schein
    before["Die bisherige implizite Annahme"] --> b1["Echter Inhalt auf der lokalen Platte"]
    after["Die ersetzte Annahme"] --> a1["Der echte Inhalt ist in der Cloud"]
    a1 --> a2["Lokal gibt es nur den Schein"]
    a2 -.-> note["Ein Platzhalter"]

Abbildung 1: Die Annahme „der echte Inhalt ist lokal“ ist, ohne dass jemand das entschieden hat, durch „der echte Inhalt ist in der Cloud; lokal gibt es nur den Schein“ ersetzt worden.

1. Zuerst das Fazit

• Desktop, Dokumente und Bilder können durch KFM unter C:\Users\<Name>\OneDrive\ verschoben worden sein. Das wird oft bei der Ersteinrichtung eines neuen PCs eingeschaltet, und eine Organisation kann es per Richtlinie massenhaft anwenden. Eine App, die einen festen Pfad voraussetzt, bricht hier.¹
• Dateien bei Bedarf ist in der aktuellen Sync-App standardmäßig an. Dateien, die auf einem anderen Gerät oder im Web erzeugt wurden, erscheinen als „nur-online“-Platzhalter ohne lokalen Inhalt.²³
• Die echte Identität eines Platzhalters ist ein Reparse Point, den die Cloud Files API verwaltet (der Minifilter cldflt.sys). Er sieht für Explorer und Datei-APIs wie eine gewöhnliche Datei aus, und das Öffnen lädt (hydriert) automatisch.⁴
• Der Zustand lässt sich aus Dateiattributen beurteilen. FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED und ähnliche sind die Marker; attrib zeigt sie als Buchstaben O, P und U. Attribute allein prüfen verursacht keinen Download.⁵⁶⁷
• Typische Unfälle in einer Business-App sind eine Kombination aus „öffnet nicht“, „langsam“, „falsch beurteilte Attribute“, „Sturm von Überwachungsereignissen“ und „Konflikt mit der Synchronisierung“. Offline oder bei gestopptem OneDrive scheitert die Hydration, und ein Stapelprozess löst den Download jeder Datei aus.⁴⁸
• Die Antwort der App-Seite ist, „Platzhalter zu respektieren“. Grundlage ist, beim Auflisten aus Attributen zu urteilen und nicht leichtfertig zu öffnen, bei Bedarf FILE_FLAG_OPEN_NO_RECALL zu nutzen und den Datenordner nicht unter OneDrive zu legen.⁹¹⁰
• Die Antwort der IT-Seite ist „Betrieb mit Pins“ und „Steuerung per Richtlinie“. Garantieren Sie echten Inhalt für Geschäftsordner mit „Immer auf diesem Gerät behalten“, und konfigurieren Sie KFM und Dateien bei Bedarf absichtlich mit Gruppenrichtlinie / Intune. Vergessen Sie nicht, dass Speicheroptimierung ungenutzte Dateien auch „wieder nur-online machen“ kann.¹¹¹²

In einem Satz: „eine im Explorer sichtbare Datei“ und „eine Datei mit echtem Inhalt auf der lokalen Platte“ sind nicht mehr dasselbe.

2. Was geschieht — KFM und Dateien bei Bedarf

2.1. Der Desktop ist vielleicht nicht mehr C:\Users\<Name>\Desktop

Die OneDrive-Sync-App hat eine Funktion namens Known Folder Move (KFM). Auf dem Einstellungsbildschirm erscheint sie als „Sicherung“, „Wichtige Ordner sichern“ und ähnlich; ist sie an, werden der echte Desktop, Dokumente und Bilder unter den OneDrive-Ordner verschoben (umgeleitet).¹

Bei der Ersteinrichtung (OOBE) eines neuen PCs präsentiert die Anmeldung mit Microsoft-Konto oder Arbeitskonto die Ordnersicherung weithin als Standardvorschlag; einfach weiterzugehen schaltet sie ein. Eine Organisation kann sie auch massenhaft anwenden, ohne den Benutzer etwas zu fragen, mit der Richtlinie „Windows-bekannte Ordner still nach OneDrive verschieben“ (KFMSilentOptIn).¹¹¹

flowchart TB
    accTitle: Zwei Wege, auf denen KFM eingeschaltet wird
    accDescr: Die Anmeldung mit einem Konto bei der Ersteinrichtung eines neuen PCs präsentiert die Ordnersicherung als Standardvorschlag und Weitergehen schaltet sie ein; in einer Organisation wendet KFMSilentOptIn sie massenhaft an, ohne den Benutzer zu fragen
    oobe["Ersteinrichtung eines neuen PCs"] --> signin["Anmeldung mit einem Konto"]
    signin --> prompt["Sicherung wird standardmäßig vorgeschlagen"]
    prompt --> on1["Weitergehen schaltet sie ein"]
    org["Organisationsrichtlinie"] --> silent["KFMSilentOptIn"]
    silent --> on2["Massenhaft angewendet ohne zu fragen"]
    on1 --> kfm["KFM an"]
    on2 --> kfm

Abbildung 2: KFM wird eingeschaltet, ohne dass es jemand merkt — entweder durch den Standardvorschlag bei der Ersteinrichtung oder durch die stille Anwendungsrichtlinie der Organisation.

Das Unbequeme ist, dass das Erscheinungsbild im Explorer sich kaum ändert. Die Shell-APIs für bekannte Ordner (SHGetKnownFolderPath und .NETs Environment.GetFolderPath) liefern den korrekten Pfad nach dem Umzug, daher läuft eine anständige App weiter. Was bricht, ist eine App, die einen festen Pfad wie C:\Users\%USERNAME%\Desktop in einer Einstellungsdatei oder im Code einbettet. Das typische Muster, dass ein Import nach einem PC-Tausch mit „Datei nicht gefunden“ scheitert, ist genau das.

flowchart TB
    accTitle: Wie eine App den Pfad nach KFM auflöst
    accDescr: Nachdem KFM den echten Desktop und ähnliche Ordner unter OneDrive verschoben hat, läuft eine App, die die APIs für bekannte Ordner nutzt, mit dem korrekten Pfad nach dem Umzug weiter, aber eine App, die einen festen Pfad einbettet, scheitert mit Datei nicht gefunden
    kfm["KFM eingeschaltet"] --> move["Echter Desktop und Ähnliches wandern unter OneDrive"]
    move --> how{"Wie löst die App den Pfad auf?"}
    how -->|APIs für bekannte Ordner| ok["Bekommt den korrekten Pfad nach dem Umzug und läuft weiter"]
    how -->|Ein fest verdrahteter Pfad| ng["Datei nicht gefunden"]

Abbildung 3: Nach KFM läuft eine App, die die APIs für bekannte Ordner nutzt, weiter, aber eine App, die einen festen Pfad fest verdrahtet, bricht hier.

2.2. Dateien bei Bedarf — sichtbar, aber ohne echten Inhalt

Die andere Spur ist Dateien bei Bedarf. In einer Umgebung, in der es an ist, ist jede Datei auf OneDrive im Explorer sichtbar, aber der Inhalt wird erst heruntergeladen, wenn die Datei geöffnet wird. Diese Funktion ist in der aktuellen Sync-App standardmäßig an, und Microsoft empfiehlt auch, sie an zu lassen.²³

Den Zustand erkennt man an den Statussymbolen im Explorer.¹³

Wichtig ist hier der mittlere Zustand. Eine Datei, die einmal geöffnet wurde und nun lokalen Inhalt hat, kann durch die Aktion „Speicherplatz freigeben“ des Benutzers oder durch Speicheroptimierung, die später kommt, wieder nur-online werden. Das ist eine Ursache für schwer reproduzierbare Ausfälle der Sorte „letzten Monat ging es noch“.³¹²

stateDiagram-v2
    accTitle: Die drei Zustände von Dateien bei Bedarf und die Übergänge
    accDescr: Eine nur-online-Datei wird beim Öffnen lokal verfügbar, aber Speicherplatz freigeben oder Speicheroptimierung können sie wieder nur-online machen, und nur eine gepinnte Datei liegt außerhalb der automatischen Freigabe
    s1: Nur online (Wolkenzeichen)
    s2: Lokal verfügbar
    s3: Gepinnt (Immer auf diesem Gerät behalten)
    s1 --> s2: Öffnen (Hydration)
    s2 --> s1: Speicherplatz freigeben
    s2 --> s1: Speicheroptimierung
    s1 --> s3: Immer auf diesem Gerät behalten
    s2 --> s3: Immer auf diesem Gerät behalten
    s3 --> s2: Pin lösen

Abbildung 4: Die drei Zustände von Dateien bei Bedarf. „Lokal verfügbar“ kann automatisch wieder nur-online werden; ein Pin liegt außerhalb davon.

3. Die echte Identität eines Platzhalters — die Cloud Files API und Reparse Points

Dateien bei Bedarf ist auf einem OS-Mechanismus aufgebaut, der in Windows 10 Version 1709 eingeführt wurde, der Cloud Files API. Die Arbeitseinheit auf Dateisystemseite ist ein Dateisystem-Minifilter namens cldflt.sys (Dienstname CldFlt, „Windows Cloud Files Filter Driver“), und OneDrive ist ein „Sync-Anbieter“, der diese API nutzt.⁴⁷

Ein Platzhalter ist technisch ein Reparse Point. Auf dem Dateisystem existieren nur Metadaten wie Name, Größe und Zeitstempel (etwa 1 KB); es gibt keine Inhaltsdaten. Wenn eine App die Datei öffnet und liest, erkennt der Minifilter die Anforderung, sagt dem Sync-Anbieter, die Daten zu übertragen, wartet auf das Ende des Downloads, und dann läuft das Lesen weiter. Dieses Holen heißt Hydration; lokalen Inhalt wegwerfen und zum Platzhalter zurückkehren heißt Dehydration.⁴

sequenceDiagram
    accTitle: Hydration beim Öffnen eines Platzhalters
    accDescr: Wenn eine App einen Platzhalter öffnet und liest, erkennt der Minifilter cldflt.sys die Anforderung, sagt dem Sync-Anbieter, die Daten zu übertragen, wartet auf das Ende des Downloads, und dann läuft das Lesen weiter
    participant app as Business-App
    participant flt as Minifilter cldflt.sys
    participant sync as Sync-Anbieter
    app->>flt: Öffnen- und Leseanforderung
    flt->>sync: Datentransfer anweisen
    sync-->>flt: Download abgeschlossen
    flt-->>app: Das Lesen läuft weiter

Abbildung 5: Ein Platzhalter-Lesen läuft weiter, nachdem der Minifilter den Sync-Anbieter die Daten hat holen lassen.

„Reparse Point“ weckt Sorge um Kompatibilität mit bestehendem Code, der „einen Reparse Point besonders behandelt, wenn er einen erkennt“, aber aus Kompatibilitätsgründen versteckt die Cloud Files API die Tatsache, dass es ein Reparse Point ist, vor allen außer der Sync-Engine und Prozessen unter %systemroot%. Aus einer gewöhnlichen App sieht es aus wie „eine gewöhnliche Datei, die nur etwas langsam zu öffnen ist“. Diese gründliche Transparenz ist zugleich bequem und der Grund, warum „die App ihre Annahmen zerbrochen bekommt, ohne es zu merken“.⁴ Der Mechanismus der Reparse Points selbst wird in „Die Tiefen von Windows I/O (Teil 5)“ erklärt.

flowchart TB
    accTitle: Verbergen des Reparse Points und der Unterschied im Aussehen
    accDescr: Die echte Identität eines Platzhalters ist ein Reparse Point, aber die Cloud Files API versteckt das vor Prozessen außer der Sync-Engine, sodass es aus einer gewöhnlichen App wie eine gewöhnliche Datei aussieht, die nur etwas langsam zu öffnen ist
    ph["Platzhalter (Reparse Point)"] --> who{"Welcher Prozess hat geöffnet?"}
    who -->|Die Sync-Engine und Ähnliches| raw["Als Reparse Point sichtbar"]
    who -->|Jede andere App| plain["Sieht aus wie eine gewöhnliche Datei"]
    plain -.-> note["Sieht nur etwas langsam zu öffnen aus"]

Abbildung 6: Die Tatsache, dass es ein Reparse Point ist, wird vor allen außer der Sync-Engine verborgen, und einer gewöhnlichen App sieht es wie eine gewöhnliche Datei aus.

In den Explorer-Eigenschaften hat ein Platzhalter das charakteristische Aussehen, dass „Größe“ die Originalgröße zeigt, während „Größe auf dem Datenträger“ fast 0 ist. Die Annahme „es hat eine Größe, also muss es echten Inhalt haben“ hält hier nicht.

flowchart TB
    accTitle: Wie ein Platzhalter in den Eigenschaften aussieht
    accDescr: In den Explorer-Eigenschaften zeigt ein Platzhalter die Originalgröße als Größe, während Größe auf dem Datenträger fast 0 ist, sodass die Annahme, es habe eine Größe und müsse daher echten Inhalt haben, nicht hält
    prop["Platzhalter-Eigenschaften"] --> size["Größe ist die Originalgröße"]
    prop --> disk["Größe auf dem Datenträger fast 0"]
    size -.-> trap["Die Annahme, es müsse echten Inhalt geben"]
    disk -.-> truth["Es gibt keinen lokalen Inhalt"]

Abbildung 7: Ein Platzhalter zeigt die Originalgröße als „Größe“, während „Größe auf dem Datenträger“ fast 0 ist.

4. Dateiattribute sagen Ihnen den Zustand

Der Platzhalterzustand wird als gewöhnliche Dateiattribute veröffentlicht. Die wichtigsten sind die folgenden.⁵

Der attrib-Befehl der Eingabeaufforderung kann diese als einzelnen Buchstaben anzeigen und setzen. O ist das Offline-Attribut, P ist gepinnt, U ist entpinnt.⁶ Die Entsprechung zum Zustand von OneDrive Dateien bei Bedarf ist in Microsofts Dokumentation so geordnet.⁷

Ein Vorbehalt. Zustandswechsel hat eine Reihenfolge. Wenn Sie eine nur-online-Datei (U) zu „lokal verfügbar“ machen wollen, lässt -p allein U gesetzt und der echte Inhalt wird nicht geholt. Microsofts Dokumentation zeigt auch das Verfahren, zuerst +p (immer verfügbar) zu tun, um den echten Inhalt herunterzuladen, und dann -p.⁷ In einem Skript, das einen bestehenden Zustand zuverlässig umschalten muss, ist es sicherer, das gegenteilige Attribut gleichzeitig zu löschen, wie in attrib +p -u.

flowchart TB
    accTitle: Die Reihenfolge vom Nur-Online zum Lokal-Verfügbar
    accDescr: attrib -p allein auf einer nur-online-Datei lässt das U-Attribut und der echte Inhalt wird nicht geholt; Sie brauchen das Verfahren, zuerst mit attrib +p den echten Inhalt herunterzuladen und dann -p
    u["Nur online (U)"] -->|nur attrib -p| stay["Bleibt U; der echte Inhalt wird nicht geholt"]
    u -->|attrib +p| pin["Gepinnt (echten Inhalt herunterladen)"]
    pin -->|attrib -p| local["Lokal verfügbar"]

Abbildung 8: Der Wechsel vom Nur-Online braucht die Reihenfolge, zuerst den echten Inhalt mit +p zu holen und dann -p.

Ein Beispiel zur Beurteilung in PowerShell. Attribute allein anzusehen verursacht keine Hydration, daher können Sie es für Untersuchung und Massenchecks mit Vertrauen nutzen.

function Test-CloudPlaceholder {
    param([Parameter(Mandatory)][string]$Path)

    $value = [int](Get-Item -LiteralPath $Path -Force).Attributes

    [pscustomobject]@{
        Path               = $Path
        Offline            = ($value -band 0x00001000) -ne 0  # FILE_ATTRIBUTE_OFFLINE
        RecallOnDataAccess = ($value -band 0x00400000) -ne 0  # Nicht der ganze Inhalt ist lokal
        Pinned             = ($value -band 0x00080000) -ne 0  # Immer auf diesem Gerät behalten
        Unpinned           = ($value -band 0x00100000) -ne 0  # Nur online
    }
}

# CSV unter dem Ordner Dokumente massenhaft prüfen (der Inhalt wird nicht heruntergeladen).
# Lösen Sie den Pfad mit der API für bekannte Ordner auf. Den Anzeigenamen
# "Documents" fest zu verdrahten kann je nach echtem Ordnernamen
# (Documents vs. ein lokalisierter Name) und der KFM-Konfiguration
# ein nicht existierender Pfad werden
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

Der Cast auf [int] liegt daran, dass .NETs Aufzählung FileAttributes Namen wie RECALL_ON_DATA_ACCESS nicht definiert. Bitweise Operationen auf dem Zahlenwert können ohne Mühe urteilen.

5. Fallen, in die eine Business-App tritt

Das ist das Hauptthema. Die Transparenz der Platzhalter ist meist bequem, aber kombiniert mit einem typischen Verarbeitungsmuster einer Business-App tritt sie in den folgenden sechs Formen zutage.

5.1. Öffnen startet automatisch einen Download — „öffnet nicht“ offline

Das Öffnen einer nur-online-Datei startet die Hydration auf der Stelle. Online, bei einer kleinen Datei, ist es so schnell, dass man es nicht merkt, aber wenn OneDrive gestoppt, abgemeldet oder pausiert ist, wenn das Netz ungesund ist oder die Datei groß ist, wird daraus „eine Datei, die existiert, aber sich nicht öffnet“. Der Fehler kann als Cloud-Datei-Familiencode wie ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, “The cloud file provider is not running”) zurückkommen oder auf der App-Seite als Timeout beobachtet werden.⁸

Eine weitere Falle ist, dass eine Existenzprüfung äquivalent zu File.Exists() und das Holen von Attributen oder Größe gelingen. Sie bekommen ein Fehlermuster, das die Intuition der lokalen Platte nicht erklären kann: „die Existenzprüfung ist durch, aber das Lesen ist gescheitert“.

flowchart TB
    accTitle: Zweige beim Zugriff auf eine nur-online-Datei
    accDescr: Eine Existenzprüfung und das Holen von Attributen und Größe gelingen, aber das Lesen des Inhalts startet die Hydration; wenn OneDrive läuft und das Netz gesund ist, kann man nach dem Download lesen, sonst scheitert man mit einem Fehler wie 0x8007016A oder einem Timeout
    check["Existenzprüfung oder Holen von Attributen oder Größe"] --> ok1["Gelingt"]
    open["Lesen des Inhalts"] --> hyd["Hydration startet"]
    hyd --> cond{"OneDrive läuft und Netz gesund?"}
    cond -->|Ja| read["Nach dem Download lesbar"]
    cond -->|Nein| err["Ein Fehler wie 0x8007016A oder ein Timeout"]

Abbildung 9: Eine Existenzprüfung kann gelingen, während ein Lesen scheitert. Erfolg oder Misserfolg hängt davon ab, ob OneDrive läuft, und vom Netz.

5.2. Ein Stapelprozess löst den Download jeder Datei aus

Richten Sie einen Stapel, der jede Datei in einem Ordner liest, eine Hash-Berechnung, eine Volltextsuche oder eine selbstgebaute Sicherung auf einen Baum unter OneDrive, und die Hydration jeder Datei, die Sie berühren, wird ausgelöst. Bei einem Ordner von mehreren GB wird der Prozess ungewöhnlich langsam, der Download füllt auch die Platte, und auf einem PC mit geringer Kapazität lädt fehlender Freiraum einen anderen Ausfall ein. Die Kapazität, die Dateien bei Bedarf sparen sollte, verschwindet in einem einzigen Vollscan.

Außerdem kann Windows, wenn eine App ohne ausdrückliche Benutzeraktion Hydration auslöst, einen Toast zeigen und dem Benutzer die Wahl zum Blockieren geben. Einmal blockiert, scheitert diese App danach weiter an Downloads (hebar über „Automatische Dateidownloads“ in Einstellungen). Das ist eine Ursache für „der Import scheitert nur auf einem bestimmten PC“.⁴

flowchart TB
    accTitle: Wie ein Stapel den Download jeder Datei auslöst
    accDescr: Ein Stapel unter OneDrive löst die Hydration jeder berührten Datei aus, verursacht Verarbeitungsverzögerung und Plattendruck, und wenn der Benutzer auf dem Toast blockiert, scheitern Downloads danach weiter
    scan["Ein Stapel unter OneDrive"] --> touch["Jede berührte Datei hydrieren"]
    touch --> cost["Verarbeitungsverzögerung und Plattendruck"]
    touch --> toast["Ein Toast kann erscheinen"]
    toast --> block{"Hat der Benutzer blockiert?"}
    block -->|Ja| fail["Downloads scheitern danach weiter"]
    block -->|Nein| cont["Der Download geht weiter"]

Abbildung 10: Ein Stapel löst die Hydration jeder Datei aus, und wird er auf dem Toast blockiert, gehen die Fehler danach weiter.

5.3. Fehlverhalten von Code, der die Attribute nicht erwartet

Code, der FILE_ATTRIBUTE_OFFLINE oder RECALL_ON_DATA_ACCESS nicht kennt, verhält sich an unerwarteten Stellen falsch.

• Attribute werden auf genaue Gleichheit geprüft (attributes == FileAttributes.Archive und ähnlich), sodass ein Platzhalter als „unerwartete Datei“ ausgeschlossen oder als Fehler behandelt wird
• Eine Ausschlussentscheidung in einem Backup- oder Sync-Werkzeug deutet das OFFLINE-Attribut als „bereits auf Band ausgelagert“ und überspringt (oder holt umgekehrt jede Datei, die es hätte ausschließen sollen)
• Eine Schreibschutzprüfung oder eine Archivbit-Operation zerbricht die Attributkombination

flowchart TB
    accTitle: Fehlverhaltensmuster von Code, der die Attribute nicht erwartet
    accDescr: Code, der Platzhalterattribute nicht kennt, verhält sich falsch als Ausschluss oder Fehlerbehandlung durch einen Gleichheitstest, Überspringen oder Vollholen durch Fehldeutung von OFFLINE, oder Zerbrechen der Attributkombination
    code["Code, der die Attribute nicht erwartet"] --> m1["Genauigkeits-Gleichheitstest"]
    code --> m2["Deutet OFFLINE falsch"]
    code --> m3["Eine Attributoperation zerbricht die Kombination"]
    m1 --> r1["Als unerwartet ausgeschlossen oder fehlerhaft"]
    m2 --> r2["Überspringen oder ein Vollholen"]

Abbildung 11: Code, der OFFLINE oder die RECALL-Familie nicht kennt, verhält sich falsch als Ausschluss, falsches Überspringen oder Attributzerstörung.

Microsofts Leitfaden für Minifilter-Entwickler sagt klar, dass man kein leichtsinniges Lesen oder Schreiben an eine Datei mit RECALL_ON_DATA_ACCESS ausgeben soll. Das Dokument zielt auf Kerneltreiber, aber der Grundsatz „den Inhalt einer Datei mit diesem Attribut anfassen = es entsteht Holkosten“ gilt unverändert für eine Usermode-App.¹⁰

5.4. Zusammenspiel von FileSystemWatcher und Synchronisierung

Überwachen Sie einen Ordner unter OneDrive mit FileSystemWatcher, und Sie bekommen nicht nur Benutzeraktionen, sondern auch eine große Zahl von Ereignissen aus der Aktivität der Sync-App. Jedes Mal, wenn eine Änderung auf einem anderen Gerät synchronisiert wird, und jedes Mal, wenn Hydration oder Dehydration Attribute oder Größe ändert, kann ein Changed-Ereignis feuern. Weiter wird ein Entwurf, der das Ergebnis einer Überwachung-und-Import zurück in denselben Ordner schreibt, zu einem „Sturm von Änderungsbenachrichtigungen“ in einer Schleife Schreiben → Upload → Attributupdate → weiteres Ereignis. Das Ausdünnen von Ereignissen und der Entwurf einer Inhaltsprüfung sind in „Praxisleitfaden für FileSystemWatcher“ behandelt, aber unter OneDrive ist der Bedarf daran eine Stufe höher.

flowchart TB
    accTitle: Eine Änderungsbenachrichtigungsschleife durch Überwachen und Zurückschreiben
    accDescr: Wenn eine überwachende App, die ein Änderungsereignis erhalten hat, das Importergebnis in denselben Ordner zurückschreibt, feuern Upload und Attributupdate der Sync-App ein weiteres Ereignis, und daraus wird eine Schleife — ein Sturm von Änderungsbenachrichtigungen
    ev["Änderungsereignis"] --> proc["Die überwachende App importiert"]
    proc --> write["In denselben Ordner zurückschreiben"]
    write --> up["Die Sync-App lädt hoch"]
    up --> attr["Attribute oder Größe werden aktualisiert"]
    attr --> ev
    sync["Sync einer Änderung von einem anderen Gerät"] -.-> ev

Abbildung 12: Das Importergebnis in denselben Ordner zurückzuschreiben wird zu einer Schleife, in der die Aktivität der Sync-App ein weiteres Ereignis erzeugt.

5.5. Sync-Konflikte während einer exklusiven Sperre und „Kopie“-Dateien

Während eine Business-App eine Datei mit exklusiver Sperre offen hat, kann die Sync-App diese Datei weder hochladen noch aktualisieren. Eine App mit lang gehaltener Sperre (eine Access-.accdb, eine Datendatei in einem Hausformat, eine Protokolldatei und ähnlich) unter OneDrive zu legen macht Sync-Fehler zum Normalzustand. Umgekehrt, wenn dieselbe Datei auf mehreren PCs bearbeitet wird, versucht die Sync-App, beide Ausgaben zu behalten, und erzeugt eine Doppeldatei mit PC-Namen oder eine Konfliktkopie wie „— Kopie“. Ein Import, der „ein Ordner, eine Datei“ voraussetzt, verhält sich auf diesem Doppel falsch. Zu den Grundlagen der Sperrkonzeption siehe „Grundlagen des wechselseitigen Ausschlusses bei der Dateiintegration“.

flowchart TB
    accTitle: Sync-Probleme durch exklusive Sperre und Mehr-PC-Bearbeitung
    accDescr: Während eine App eine Datei mit exklusiver Sperre offen hat, kann die Sync-App nicht aktualisieren und Sync-Fehler werden zum Normalzustand; das Bearbeiten derselben Datei auf mehreren PCs erzeugt eine Konfliktkopie und die Annahme ein-Ordner-eine-Datei bricht zusammen
    lock["Die App öffnet mit exklusiver Sperre"] --> nosync["Kein Sync möglich; Fehler werden normal"]
    multi["Dieselbe Datei wird auf mehreren PCs bearbeitet"] --> conflict["Eine Konfliktkopie wird erzeugt"]
    conflict --> dup["Ein Doppel mit PC-Namen oder Kopie"]
    dup --> bad["Die Annahme ein-Ordner-eine-Datei bricht zusammen"]

Abbildung 13: Eine exklusive Sperre macht Sync-Fehler zum Normalzustand, und Bearbeitung auf mehreren PCs lädt Fehlverhalten durch eine Konfliktkopie ein.

5.6. Antivirus und der Suchindexer lösen Hydration aus

Nicht nur die Business-App liest Dateiinhalte. Ein Vollscan durch Antivirussoftware und der Suchindexer lösen ebenfalls Hydration aus, wenn sie den Inhalt eines Platzhalters anfassen. Microsoft Defender und ähnliche Produkte überspringen Dateien mit dem Attribut RECALL_ON_DATA_ACCESS beim On-Demand-Scan, aber das ist eine produktseitige Antwort, und Sie können nicht annehmen, dass jedes Sicherheitsprodukt dieselbe Sorgfalt zeigt. Sehen Sie Symptome wie „Netz und Platte gehen jede Nacht zur Scanzeit in die Knie“ oder „Dateien, die nur-online sein sollten, sind bis zum Morgen alle materialisiert“, verdächtigen Sie diese Linie.¹⁴

flowchart TB
    accTitle: Hydration durch ein Sicherheitsprodukt oder den Suchindexer
    accDescr: Wenn ein Vollscan oder der Suchindexer den Inhalt eines Platzhalters anfasst, überspringt ein Produkt, das das RECALL-Attribut respektiert, aber ein Produkt, das das nicht tut, hydriert jede Datei und verursacht nächtlichen Bandbreitendruck oder morgendliche Materialisierung
    av["Ein Vollscan oder der Suchindexer"] --> care{"Respektiert das RECALL-Attribut?"}
    care -->|Ein Produkt, das es respektiert| skip["Überspringt den Platzhalter"]
    care -->|Ein Produkt, das das nicht tut| hyd["Fasst den Inhalt an und hydriert"]
    hyd --> sym1["Bandbreite und Platte gehen nachts in die Knie"]
    hyd --> sym2["Bis zum Morgen sind die Dateien alle materialisiert"]

Abbildung 14: Ein Scan, der das Attribut nicht respektiert, löst die Hydration jeder Datei aus und erscheint als nächtliche Last oder morgendliche Materialisierung.

6. Antwort der App-Entwicklung — Platzhalter respektieren

Die Grundlinie als Entwickler ist, einen Platzhalter nicht als „eine kaputte Datei“, sondern als „eine Datei mit Holkosten“ zu behandeln.

• Urteilen Sie beim Auflisten aus Attributen und öffnen Sie nicht leichtfertig. Bei einem Ordnerscan bestätigen Sie zuerst aus Attributen (die Beurteilung in Kapitel 4), ob sie nur-online ist, und öffnen Sie nur Dateien, deren Inhalt Sie brauchen. Geben Sie Verarbeitung, die „nicht tödlich ist, wenn sie fehlt“ — Protokollsammlung, Hash-Berechnung, Vorschau-Erzeugung — die Option, Platzhalter zu überspringen.

// Werte, die FileAttributes in .NET nicht definiert, als Zahlen definieren
const FileAttributes RecallOnDataAccess = (FileAttributes)0x00400000;
const FileAttributes RecallOnOpen       = (FileAttributes)0x00040000;

static bool IsCloudPlaceholder(FileAttributes attributes) =>
    (attributes & (RecallOnDataAccess | RecallOnOpen | FileAttributes.Offline)) != 0;

foreach (var file in new DirectoryInfo(watchFolder).EnumerateFiles("*.csv"))
{
    if (IsCloudPlaceholder(file.Attributes))
    {
        log.Warn($"{file.Name} ist nur online; diesmal überspringen");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: Der Weg, beim Auflisten aus Attributen zu urteilen und dann zu öffnen
    accDescr: Bei einem Ordnerscan zuerst Attribute beim Auflisten bestätigen; ist es ein Platzhalter, überspringen und ein Warnprotokoll hinterlassen, und den Import nur auf den anderen Dateien ausführen, damit leichtsinnige Hydration vermieden wird
    enum["Attribute beim Auflisten bestätigen"] --> ph{"Platzhalter?"}
    ph -->|Ja| skip["Überspringen und ein Warnprotokoll hinterlassen"]
    ph -->|Nein| imp["Den Import ausführen"]
    skip -.-> note["Die Linie, nur Dateien zu öffnen, deren Inhalt man braucht"]

Abbildung 15: Urteilen Sie beim Auflisten aus Attributen und überspringen Sie einen Platzhalter, ohne ihn zu öffnen, damit leichtsinnige Hydration vermieden wird.

• Beachten Sie, dass FILE_FLAG_OPEN_NO_RECALL keine Garantie für „nicht herunterladen“ ist. Dieses Flag auf CreateFile anzugeben kann die Absicht anzeigen, dass „gewonnene Daten auf der Remote-Seite bleiben und nicht auf lokalen Speicher zurückgeschrieben werden sollen“. Es ist jedoch ein Flag nur dafür, gewonnene Daten nicht lokal resident zu machen; wenn Sie den Inhalt lesen, findet der Datentransfer selbst trotzdem statt. Wollen Sie Bandbreite und Latenz selbst vermeiden, enden Sie bei Attributen, Größe und Zeitstempeln allein — fordern Sie keinen Lesezugriff an (öffnen Sie mit Zugriffsrechten 0, nutzen Sie Metadaten aus dem Auflistungsergebnis). Das ist am sichersten.⁹

flowchart TB
    accTitle: Wirkung und Grenzen von FILE_FLAG_OPEN_NO_RECALL
    accDescr: FILE_FLAG_OPEN_NO_RECALL ist ein Flag, gewonnene Daten nicht lokal resident zu machen; wenn Sie den Inhalt lesen, findet der Datentransfer selbst trotzdem statt, daher ist es am sichersten, beim Vermeiden des Transfers bei Metadaten wie Attributen zu enden
    flag["Mit dem Flag NO_RECALL öffnen"] --> read["Den Inhalt lesen"]
    read --> transfer["Ein Datentransfer findet statt"]
    transfer --> nolocal["Es wird nicht lokal resident"]
    meta["Bei Metadaten allein enden"] --> safe["Kein Transfer; am sichersten"]

Abbildung 16: FILE_FLAG_OPEN_NO_RECALL verhindert nur, lokal resident zu werden; wollen Sie den Transfer selbst vermeiden, enden Sie bei Metadaten allein.

• Schreiben Sie „das liegt unter OneDrive“ in die Fehlermeldung. Bei einem Lesefehler reduziert allein die Bestätigung, ob der Zielpfad unter %OneDrive% liegt, und das Einfügen in die Meldung die Triage-Zeit für Feld und Helpdesk stark. Erkennen Sie einen Cloud-Datei-Familienfehler wie 0x8007016A, ist das Ideal, dem Benutzer zu sagen „bitte prüfen Sie den Zustand von OneDrive“.
• Legen Sie den Datenordner der App nicht unter OneDrive. In einer KFM-Umgebung liegt auch „Dokumente“ unter OneDrive. Legen Sie Einstellungen, Datenbank und Arbeitsdateien der App in %ProgramData% oder %LocalAppData%, und wählen Sie Desktop oder Dokumente nicht als Standard-Speicherort oder Standard-Importordner. Wie man entscheidet, was wohin kommt, ist in „Wie Windows-Apps lokale Daten speichern sollten“ zusammengefasst.
• Entscheiden Sie das Verhalten, wenn der Benutzer einen Ort unter OneDrive wählt. Für eine App, die den Benutzer einen Speicherort wählen lässt, nehmen Sie vorab in die Spezifikation eine Entwurfsentscheidung auf, etwa zu warnen, wenn der gewählte Pfad unter OneDrive liegt (unter dem Pfad der Umgebungsvariablen OneDrive / OneDriveCommercial), oder nur die Platzierung einer Sperrdatei oder einer DB zu verweigern.

7. Antwort der IT-Seite — mit Pins und Richtlinie steuern

Aus der IT-Position ist der realistische Betrieb nicht „Dateien bei Bedarf ganz abschalten“, sondern echten Inhalt nur dort zu garantieren, wo das Geschäft ihn braucht.

• Pinnen Sie die Ordner, die eine Business-App liest. Wählen Sie „Immer auf diesem Gerät behalten“ im Explorer-Kontextmenü, oder führen Sie attrib +p -u <folder> /s /d aus einem Image-Skript aus (Sie geben -u gleichzeitig an, damit eine Mischung bereits nur-online-Dateien zuverlässig auf gepinnt umgeschaltet wird). Eine gepinnte Datei hat ihren echten Inhalt lokal garantiert und liegt auch außerhalb der späteren automatischen Umwandlung ins Nur-Online.⁷²
• Konfigurieren Sie KFM und Dateien bei Bedarf „absichtlich“, nicht „es war an, als wir es merkten“. Die wichtigsten Richtlinien (Gruppenrichtlinie / Intune) sind die folgenden.¹¹¹

• Wissen Sie, wie Speicheroptimierung sich bewegt. Speicheroptimierung hat eine Funktion, die Cloud-Dateien, die eine Anzahl Tage nicht geöffnet wurden, automatisch wieder nur-online macht, und Sie können die Tageszahl mit der Richtlinie (ConfigStorageSenseCloudContentDehydrationThreshold) konfigurieren. Der Standard ist 0 (nicht automatisch zurückführen), aber wenn ein Benutzer es vom Einstellungsbildschirm eingeschaltet hat oder die Organisation es für Geräte mit geringer Kapazität konfiguriert hat, geschieht „eine Datei, die letzte Woche aufging, ist wieder ein Wolkensymbol“ als Normalverhalten. Eine gepinnte Datei liegt außerhalb, daher wirkt „Geschäftsordner pinnen“ auch hier.¹²²

flowchart TB
    accTitle: Zweige der automatischen Nur-Online-Umwandlung durch Speicheroptimierung
    accDescr: Bei der automatischen Freigabe der Speicheroptimierung liegt eine gepinnte Datei außerhalb und der echte Inhalt bleibt; eine ungepinnte Datei, die eine Anzahl Tage nicht geöffnet wurde, wird wieder nur-online
    ss["Automatische Freigabe der Speicheroptimierung"] --> pin{"Gepinnt?"}
    pin -->|Ja| stay["Außerhalb; der echte Inhalt bleibt"]
    pin -->|Nein| old{"Eine Anzahl Tage nicht geöffnet?"}
    old -->|Ja| dehyd["Wieder nur-online"]
    old -->|Nein| keep["Der echte Inhalt bleibt"]
    ss -.-> def["Standard 0 führt nicht automatisch zurück"]

Abbildung 17: Speicheroptimierung macht eine Datei, die eine Anzahl Tage nicht geöffnet wurde, wieder nur-online, aber ein Pin liegt außerhalb.

• Schätzen Sie die Wirkung, bevor Sie Dateien bei Bedarf deaktivieren. Das Deaktivieren von FilesOnDemandEnabled wird zur klassischen Voll-Download-Synchronisierung, aber Plattenverbrauch und Bandbreitenlast der ersten Synchronisierung springen. Microsoft empfiehlt, es an zu lassen, und Sie sollten das Deaktivieren als begrenzte Maßnahme behandeln, nachdem Sie bestätigt haben, dass „das Datenvolumen der Zielbenutzer klein ist“ und „Plattenreserve da ist“.¹¹²
• Bauen Sie es in das Supportverfahren ein. Das Triage-Verfahren des nächsten Kapitels in die Anfragevorlage „eine Datei auf dem Desktop öffnet sich nicht“ zu legen hält die Qualität der Antwort, auch wenn die bearbeitende Person wechselt.

8. Triage-Verfahren — wenn man gefragt wird „die Datei öffnet sich nicht“

Wenn Sie die Anfrage entgegennehmen, bestätigen Sie von oben nach unten.

Der Notbehelf ist, den Zielordner rechtszuklicken und „Immer auf diesem Gerät behalten“ zu wählen (oder attrib +p /s /d). Das richtet den echten Inhalt lokal aus, und das Geschäft kann weitergehen. Darüber entscheiden Sie, ob die wesentliche Ursache auf der App-Seite (Kapitel 6) oder der IT-Seite (Kapitel 7) liegt, als dauerhafte Antwort.

flowchart TB
    accTitle: Der Weg vom Notbehelf zur dauerhaften Antwort
    accDescr: Als Notbehelf den Zielordner auf Immer auf diesem Gerät behalten zu setzen richtet den echten Inhalt lokal aus, sodass das Geschäft weitergehen kann; darüber entscheiden Sie, ob die wesentliche Ursache auf der App- oder der IT-Seite liegt, und gehen zur dauerhaften Antwort
    aid["Als Notbehelf pinnen"] --> restore["Der echte Inhalt ist lokal ausgerichtet"]
    restore --> resume["Das Geschäft geht weiter"]
    resume --> judge{"Wo liegt die wesentliche Ursache?"}
    judge -->|App-Seite| dev["Zur Antwort von Kapitel 6"]
    judge -->|IT-Seite| ops["Zur Antwort von Kapitel 7"]

Abbildung 18: Der Notbehelf ist zu pinnen, den echten Inhalt auszurichten und das Geschäft fortzusetzen; die dauerhafte Antwort geht weiter, nachdem entschieden ist, ob es die App- oder die IT-Seite ist.

Haben Sie bis hier bestätigt und „der Pfad liegt nicht unter OneDrive“ und „es ist auch kein Platzhalter“, gehen Sie zu anderen Standardursachen wie einem Freigabeordner oder Pfadlänge. „Die Fallstricke von Netzlaufwerken und UNC-Pfaden“ und „MAX_PATH und die Fallstricke von Windows-Pfaden und Dateinamen“ sind die Karte für das, was kommt.

9. Zusammenfassung

• KFM kann den echten Desktop, Dokumente und Bilder unter C:\Users\<Name>\OneDrive\ verschoben haben. Eine App, die einen festen Pfad voraussetzt, bricht hier. Auflösen mit den APIs für bekannte Ordner ist der erste Schritt.
• Dateien bei Bedarf ist standardmäßig an, und Platzhalter ohne lokalen Inhalt existieren selbstverständlich. Ein Platzhalter ist ein Reparse Point der Cloud Files API (cldflt.sys), und das Öffnen hydriert automatisch.
• Der Zustand lässt sich aus Dateiattributen beurteilen (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED) und erscheint in attrib als O, P und U. Attribute allein prüfen verursacht keinen Download.
• Unfälle von Business-Apps erscheinen als Hydration-Fehler offline, Voll-Download durch einen Stapelprozess, Code, der die Attribute nicht erwartet, Zusammenspiel von FileSystemWatcher und Sync, Konflikt zwischen exklusiver Sperre und Sync, und Hydration durch ein Sicherheitsprodukt.
• Auf der App-Seite sind die Grundlagen „aus Attributen urteilen und nicht leichtfertig öffnen“, „den Datenordner nicht unter OneDrive legen“ und „beim Fehler sagen, dass es unter OneDrive liegt“.
• Auf der IT-Seite erzeugen Sie den beabsichtigten Zustand mit „Pinnen von Geschäftsordnern“ und „Richtliniensteuerung von KFM, Dateien bei Bedarf und Speicheroptimierung“.
• Die Triage lässt sich mechanisch in der Reihenfolge Pfad → attrib → OneDrive läuft → Netz → Freiraum → Aufzeichnung gehen.

Wenn Sie das nächste Mal gefragt werden „die Datei ist da, aber sie öffnet sich nicht“, fragen Sie zuerst dies.

Liegt diese Datei wirklich auf der lokalen Platte? Oder sitzt dort nur der Schein der Cloud?

Verwandte Artikel

• Die Tiefen von Windows I/O (Teil 5) — NTFS-Interna: Das Dateisystem anhand des MFT verstehen
• Praxisleitfaden für FileSystemWatcher - Umgang mit verpassten und doppelten Ereignissen
• Die Fallstricke von Netzlaufwerken und UNC-Pfaden ── Fileserver (Freigabeordner) in Business-Anwendungen richtig einsetzen
• Grundlagen des wechselseitigen Ausschlusses bei der Dateiintegration - Best Practices für Dateisperren und atomare Claims
• Wie Windows-Apps lokale Daten speichern sollten — Entscheidungstabelle für SQLite / JSON / Registrierung / Access
• MAX_PATH und die Fallstricke von Windows-Pfaden und Dateinamen ── Das 260-Zeichen-Limit, reservierte Namen, abschließende Punkte und Groß-/Kleinschreibung

Verwandte Beratungsbereiche

KomuraSoft LLC übernimmt die Untersuchung von Business-App-Ausfällen, die OneDrive und Cloud-Speicher betreffen — „ein Import, der funktionierte, funktioniert nach einem PC-Tausch nicht mehr“, „eine Datei öffnet sich nur auf einem bestimmten PC nicht“ —, Entwurf und Behebung von Dateiverarbeitung und Überwachung, die Platzhalter voraussetzen, und Reviews der Speicherortgestaltung in einer KFM- / Dateien-bei-Bedarf-Umgebung. Beim Isolieren des Symptoms zu beginnen ist in Ordnung — bitte zögern Sie nicht, uns zu erreichen.

• Windows-App-Entwicklung
• Fehleruntersuchung und Ursachenanalyse
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Eine Business-App sagt „Datei nicht gefunden“ und kann eine CSV auf dem Desktop nicht lesen. Warum?

In vielen Fällen wurde der Desktop-Ordner selbst durch OneDrives Known Folder Move (KFM) nach C:\Users\<Benutzername>\OneDrive\Desktop verschoben, oder die Datei ist ein nur-online-Platzhalter geworden. Eine App, die einen festen Pfad wie C:\Users\<Benutzername>\Desktop voraussetzt, findet die Datei nach dem Umzug nicht. Selbst wenn der Pfad stimmt, kann eine nur-online-Datei fehlschlagen, wenn OneDrive gestoppt oder das Netz ungesund ist. Prüfen Sie zuerst, ob der Zielpfad unter OneDrive liegt, und mit attrib, ob U (nur online) gesetzt ist. Als Notbehelf sichern Sie den echten Inhalt lokal mit „Immer auf diesem Gerät behalten“ im Kontextmenü.

Kann ein Programm erkennen, ob eine Datei nur online ist?

Ja. Ein nur-online-Platzhalter trägt Attribute wie FILE_ATTRIBUTE_OFFLINE und FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000), sodass Sie den Zustand aus den Dateiattributen beurteilen können, ohne den Inhalt herunterzuladen. Attribute lesen oder einen Ordner auflisten verursacht keine Hydration (Download). In .NET sind manche Werte auf FileAttributes nicht definiert; Sie casten auf eine Ganzzahl und prüfen bitweise. Wenn Sie wirklich öffnen müssen, ohne den Inhalt zu lesen, steht etwa FILE_FLAG_OPEN_NO_RECALL von CreateFile zur Verfügung.

Löst das Abschalten von Dateien bei Bedarf das Problem?

Behandeln Sie das Abschalten als letzten Ausweg. Das Deaktivieren lädt jede Datei im Sync-Bereich lokal herunter, sodass Plattenkapazität und Netzlast der ersten Synchronisierung groß werden; Microsoft empfiehlt auch, es eingeschaltet zu lassen. Praktisch ist es flexibler, nur die Ordner, die eine Business-App liest, auf „Immer auf diesem Gerät behalten“ zu setzen (zu pinnen). Grundsätzlicher und zuverlässiger ist, die Daten- und Importordner der App nicht unter OneDrive-Verwaltung zu legen.

Ich habe „Immer auf diesem Gerät behalten“ gesetzt, aber manche Dateien werden wieder zum Wolkensymbol. Warum?

Prüfen Sie zuerst mit attrib, ob die Datei wirklich den Pin hat (P-Attribut). Eine gepinnte Datei liegt außerhalb der automatischen Umwandlung ins Nur-Online durch Speicheroptimierung, aber eine Datei, die nur „lokal verfügbar“ ist, weil jemand sie geöffnet hat, ohne zu pinnen, kann je nach Speicheroptimierungs-Einstellungen und Richtlinie nach einer Frist wieder nur-online werden. Die eigene Aktion „Speicherplatz freigeben“ und eine Richtlinie, die Teamwebsite-Dateien nur-online macht (DehydrateSyncedTeamSites), bringen das Wolkensymbol ebenfalls zurück. Ordner, die für das Geschäft lokal bleiben müssen, betreiben Sie durch Pinnen auf Ordnerebene.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.