OneDrive «File Sesuai Permintaan» dan aplikasi bisnis — asumsi yang dirusak oleh placeholder, dan cara mengatasinya

«Aplikasi bisnis tidak bisa membaca CSV yang disimpan di desktop.» «Proses impor yang selama ini berjalan gagal dengan «file tidak ditemukan» setelah PC diganti.» «Di Explorer file-nya kelihatan, tetapi membuka dari aplikasi justru error.» — Beberapa tahun terakhir, jenis konsultasi pelanggan ini sudah menjadi hal yang biasa.

Saat ditelusuri, penyebabnya sering bukan bug aplikasi, melainkan «pencadangan otomatis Desktop dan Dokumen» OneDrive (Known Folder Move, KFM) dan «File Sesuai Permintaan». Isi nyata desktop sudah pindah ke C:\Users\<nama>\OneDrive\Desktop, dan sebagian file yang terlihat di sana adalah «placeholder» tanpa isi lokal. Pengguna maupun staf TI terus memakai PC tanpa menyadari perubahan ini.

Dengan kata lain, asumsi implisit aplikasi bisnis bahwa «file ada di disk lokal» telah, tanpa disadari, diganti oleh asumsi bahwa «file ada di cloud, dan di lokal hanya ada tampilannya». Ditujukan kepada staf TI usaha kecil-menengah dan pengembang aplikasi Windows, artikel ini merapikan — berdasarkan informasi primer Microsoft Learn — cara kerja placeholder, penilaian keadaan dari atribut file, jebakan khas aplikasi bisnis, penanganan di sisi pengembangan dan di sisi TI, serta prosedur pemilahan ketika ada keluhan «file tidak bisa dibaca».

flowchart TB
    accTitle: Penggantian asumsi implisit aplikasi bisnis
    accDescr: Asumsi implisit aplikasi bisnis bahwa file ada di disk lokal telah, tanpa disadari, diganti oleh asumsi bahwa isi nyata ada di cloud dan di lokal hanya ada tampilannya
    before["Asumsi implisit tradisional"] --> b1["Isi nyata di disk lokal"]
    after["Asumsi yang menggantikannya"] --> a1["Isi nyata ada di cloud"]
    a1 --> a2["Di lokal hanya ada tampilan"]
    a2 -.-> note["Placeholder"]

Gambar 1: Asumsi «isi nyata ada di lokal» telah, tanpa disadari, diganti oleh «isi nyata di cloud; di lokal hanya tampilan».

1. Kesimpulan dulu

• Desktop, Dokumen, dan Gambar mungkin sudah dipindahkan ke bawah C:\Users\<nama>\OneDrive\ oleh KFM. Ini mudah menyala saat penyiapan awal PC baru, dan organisasi juga dapat menerapkannya massal lewat kebijakan. Aplikasi yang mengasumsikan jalur tetap patah di sini.¹
• File Sesuai Permintaan menyala secara default di aplikasi sinkronisasi saat ini. File yang dibuat di perangkat lain atau di Web muncul sebagai placeholder «hanya-online» tanpa isi lokal.²³
• Identitas placeholder adalah titik reparse yang dikelola Cloud Files API (minifilter cldflt.sys). Ia tampak sebagai file biasa bagi Explorer maupun API file, dan membukanya mengunduh (menghidrasi) secara otomatis.⁴
• Keadaan dapat dinilai dari atribut file. FILE_ATTRIBUTE_OFFLINE, RECALL_ON_DATA_ACCESS, PINNED, UNPINNED, dan semacamnya adalah penanda, dan perintah attrib menampilkannya sebagai huruf O, P, dan U. Memeriksa atribut saja tidak memicu unduhan.⁵⁶⁷
• Kecelakaan khas aplikasi bisnis adalah kombinasi «tidak bisa dibuka», «lambat», «atribut salah dinilai», «badai peristiwa pantauan», dan «konflik dengan sinkronisasi». Saat luring atau OneDrive berhenti, hidrasi gagal, dan proses batch memicu unduhan semua file.⁴⁸
• Penanganan sisi aplikasi adalah «menghormati placeholder». Dasarnya: menilai dari atribut saat enumerasi dan tidak membuka semena-mena, memakai FILE_FLAG_OPEN_NO_RECALL jika perlu, dan tidak menaruh folder data di bawah OneDrive.⁹¹⁰
• Penanganan sisi TI adalah «operasi dengan pin» dan «kendali lewat kebijakan». Jamin isi nyata folder bisnis dengan «Selalu simpan di perangkat ini», lalu konfigurasikan KFM dan File Sesuai Permintaan dengan sengaja lewat Kebijakan Grup / Intune. Jangan lupa Storage Sense juga dapat «mengembalikan file yang tidak dipakai ke hanya-online».¹¹¹²

Dalam satu kalimat: «file yang terlihat di Explorer» dan «file yang punya isi nyata di disk lokal» sudah bukan hal yang sama.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 16, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

2. Apa yang sedang terjadi — KFM dan File Sesuai Permintaan

2.1. Desktop mungkin bukan lagi C:\Users\<nama>\Desktop

Aplikasi sinkronisasi OneDrive punya fitur Known Folder Move (KFM). Di layar pengaturan ia ditampilkan sebagai «Cadangan», «Cadangkan folder penting», dan semacamnya; jika diaktifkan, isi nyata Desktop, Dokumen, dan Gambar dipindahkan (dialihkan) ke bawah folder OneDrive.¹

Saat penyiapan awal PC baru (OOBE), jika pengguna masuk dengan akun Microsoft atau akun kerja, pencadangan folder sering diusulkan secara default; jika alur itu dilanjutkan, konfigurasi yang mengaktifkannya sudah sangat umum. Di organisasi, kebijakan «Windows known folders to OneDrive secara senyap» (KFMSilentOptIn) juga memungkinkan penerapan massal tanpa menanyai pengguna.¹¹¹

flowchart TB
    accTitle: Dua jalur yang mengaktifkan KFM
    accDescr: Saat penyiapan awal PC baru, masuk ke akun mengusulkan pencadangan folder secara default dan mengaktifkannya jika dilanjutkan; di organisasi, kebijakan KFMSilentOptIn menerapkan massal tanpa menanyai pengguna
    oobe["Penyiapan awal PC baru"] --> signin["Masuk ke akun"]
    signin --> prompt["Pencadangan diusulkan secara default"]
    prompt --> on1["Dilanjutkan, maka aktif"]
    org["Kebijakan organisasi"] --> silent["KFMSilentOptIn"]
    silent --> on2["Penerapan massal tanpa menanyai pengguna"]
    on1 --> kfm["KFM aktif"]
    on2 --> kfm

Gambar 2: KFM menyala tanpa disadari, lewat usulan default saat penyiapan awal atau kebijakan penerapan senyap organisasi.

Yang merepotkan: tampilan di Explorer hampir tidak berubah. API known folder shell (SHGetKnownFolderPath atau Environment.GetFolderPath di .NET) mengembalikan jalur yang benar setelah pemindahan, sehingga aplikasi yang ditulis dengan rapi tetap berjalan. Yang patah adalah aplikasi yang menanam jalur tetap seperti C:\Users\%USERNAME%\Desktop di berkas pengaturan atau di kode. Pola klasik proses impor yang gagal dengan «file tidak ditemukan» setelah PC diganti adalah ini.

flowchart TB
    accTitle: Bagaimana resolusi jalur aplikasi setelah KFM
    accDescr: Setelah KFM memindahkan isi Desktop dan sejenisnya ke bawah OneDrive, aplikasi yang memakai API known folder tetap mendapat jalur yang benar dan berjalan, sementara aplikasi yang menanam jalur tetap gagal dengan file tidak ditemukan
    kfm["KFM diaktifkan"] --> move["Isi Desktop dan sejenisnya pindah ke bawah OneDrive"]
    move --> how{"Bagaimana aplikasi menyelesaikan jalur?"}
    how -->|API known folder| ok["Mendapat jalur yang benar setelah pemindahan dan tetap berjalan"]
    how -->|Jalur tetap tertulis langsung| ng["File tidak ditemukan"]

Gambar 3: Setelah KFM, aplikasi yang memakai API known folder tetap berjalan, tetapi aplikasi yang menulis jalur tetap langsung patah di sini.

2.2. File Sesuai Permintaan — kelihatan, tetapi isinya tidak ada

Pemain utama yang lain adalah «File Sesuai Permintaan» (Files On-Demand). Di lingkungan yang aktif, semua file di OneDrive terlihat di Explorer, tetapi isinya tidak diunduh sampai dibuka. Fitur ini menyala secara default di aplikasi sinkronisasi saat ini, dan Microsoft juga merekomendasikan tetap mengaktifkannya.²³

Keadaan dibedakan dari ikon status di Explorer.¹³

Yang penting di sini adalah keadaan tengah. File yang sekali dibuka sehingga isinya ada di lokal pun dapat kembali ke hanya-online, lewat operasi «Kosongkan ruang» oleh pengguna atau lewat Storage Sense yang dibahas kemudian. Ini salah satu penyebab gangguan dengan reproduksi rendah bertipe «bulan lalu masih berjalan».³¹²

stateDiagram-v2
    accTitle: Tiga keadaan File Sesuai Permintaan dan transisinya
    accDescr: File hanya-online menjadi tersedia secara lokal saat dibuka, tetapi operasi Kosongkan ruang atau Storage Sense dapat mengembalikannya ke hanya-online; hanya file yang disematkan yang berada di luar pembebasan otomatis
    s1: Hanya-online (ikon awan)
    s2: Tersedia secara lokal
    s3: Disematkan (Selalu simpan di perangkat ini)
    s1 --> s2: Dibuka (hidrasi)
    s2 --> s1: Kosongkan ruang
    s2 --> s1: Storage Sense
    s1 --> s3: Selalu simpan di perangkat ini
    s2 --> s3: Selalu simpan di perangkat ini
    s3 --> s2: Lepas sematan

Gambar 4: Tiga keadaan File Sesuai Permintaan. «Tersedia secara lokal» dapat kembali otomatis ke hanya-online; penyematan berada di luar sasaran itu.

3. Identitas placeholder — Cloud Files API dan titik reparse

File Sesuai Permintaan diimplementasikan di atas mekanisme OS bernama Cloud Files API, yang diperkenalkan di Windows 10 versi 1709. Unit yang bekerja di sisi sistem file adalah minifilter sistem file cldflt.sys (nama layanan CldFlt, «Windows Cloud Files Filter Driver»), dan OneDrive adalah salah satu «penyedia sinkronisasi» yang memakai API ini.⁴⁷

Secara teknis, placeholder adalah titik reparse. Di sistem file hanya ada metadata seperti nama file, ukuran, dan cap waktu (sekitar 1 KB); data isinya tidak ada. Ketika aplikasi membuka dan membaca file, minifilter mendeteksi permintaan, memerintahkan penyedia sinkronisasi mentransfer data, lalu menunggu unduhan selesai sebelum pembacaan berlanjut. Pengambilan ini disebut hidrasi; sebaliknya, membuang isi lokal dan mengembalikan file ke placeholder disebut dehidrasi.⁴

sequenceDiagram
    accTitle: Hidrasi saat placeholder dibuka
    accDescr: Ketika aplikasi membuka dan membaca placeholder, minifilter cldflt.sys mendeteksi permintaan, memerintahkan penyedia sinkronisasi mentransfer data, lalu pembacaan berlanjut setelah unduhan selesai
    participant app as Aplikasi bisnis
    participant flt as Minifilter cldflt.sys
    participant sync as Penyedia sinkronisasi
    app->>flt: Permintaan buka dan baca
    flt->>sync: Perintah transfer data
    sync-->>flt: Unduhan selesai
    flt-->>app: Pembacaan berlanjut

Gambar 5: Pembacaan placeholder berlanjut setelah minifilter menyuruh penyedia sinkronisasi mengambil data.

Mendengar «titik reparse» membuat orang khawatir tentang kompatibilitas dengan kode lama yang «memperlakukan khusus jika titik reparse terdeteksi», tetapi demi kompatibilitas Cloud Files API menyembunyikan bahwa itu titik reparse dari proses selain mesin sinkronisasi dan proses di bawah %systemroot%. Bagi aplikasi biasa, file itu hanya «file biasa yang agak lambat dibuka». Transparansi yang ketat itulah yang sekaligus membuatnya nyaman dan menjadi sebab asumsi aplikasi dipecah tanpa aplikasi menyadarinya.⁴ Cara kerja titik reparse sendiri dijelaskan di «Struktur internal NTFS».

flowchart TB
    accTitle: Penyembunyian titik reparse dan perbedaan tampilan
    accDescr: Identitas placeholder adalah titik reparse, tetapi Cloud Files API menyembunyikannya dari proses selain mesin sinkronisasi, sehingga aplikasi biasa melihatnya sebagai file biasa yang hanya agak lambat dibuka
    ph["Placeholder (titik reparse)"] --> who{"Proses yang membuka?"}
    who -->|Mesin sinkronisasi dan sejenisnya| raw["Terlihat sebagai titik reparse"]
    who -->|Aplikasi lain| plain["Terlihat sebagai file biasa"]
    plain -.-> note["Hanya tampak agak lambat dibuka"]

Gambar 6: Status sebagai titik reparse disembunyikan dari selain mesin sinkronisasi, dan aplikasi biasa melihatnya sebagai file biasa.

Di properti Explorer, placeholder punya tampilan khas: «Ukuran» menampilkan ukuran asli, tetapi «Ukuran di disk» hampir 0. Anggapan «ada ukuran, jadi pastilah ada isinya» tidak berlaku di sini.

flowchart TB
    accTitle: Tampilan properti placeholder
    accDescr: Pada properti Explorer, placeholder menampilkan ukuran asli di Ukuran tetapi Ukuran di disk hampir 0, sehingga anggapan bahwa ada ukuran berarti ada isi tidak berlaku
    prop["Properti placeholder"] --> size["Ukuran adalah ukuran asli"]
    prop --> disk["Ukuran di disk hampir 0"]
    size -.-> trap["Anggapan bahwa isinya pasti ada"]
    disk -.-> truth["Tidak ada isi lokal"]

Gambar 7: Placeholder menampilkan ukuran asli di «Ukuran», tetapi «Ukuran di disk» hampir 0.

4. Keadaan dapat diketahui dari atribut file

Keadaan placeholder dipublikasikan sebagai atribut file biasa. Yang utama adalah sebagai berikut.⁵

Perintah attrib di Command Prompt dapat menampilkan dan mengatur ini sebagai satu huruf. O adalah atribut offline, P adalah sematan, U adalah tidak disematkan.⁶ Korespondensinya dengan keadaan File Sesuai Permintaan OneDrive dirapikan di dokumentasi Microsoft sebagai berikut.⁷

Ada satu catatan. Peralihan keadaan punya urutan. Jika file hanya-online (U) ingin dijadikan «tersedia secara lokal», menjalankan -p saja meninggalkan U dan isi tidak diambil. Dokumentasi Microsoft juga menunjukkan prosedur: dulu +p (selalu tersedia) agar isi diunduh, baru -p.⁷ Pada skrip yang harus mengganti keadaan yang ada secara andal, sekaligus melepas atribut sebaliknya, misalnya attrib +p -u, lebih aman.

flowchart TB
    accTitle: Urutan peralihan dari hanya-online ke tersedia secara lokal
    accDescr: Menjalankan attrib -p saja pada file hanya-online meninggalkan atribut U dan isi tidak diambil; prosedur yang diperlukan adalah mengunduh isi dulu dengan attrib +p, lalu -p
    u["Hanya-online (U)"] -->|hanya attrib -p| stay["Tetap U; isi tidak diambil"]
    u -->|attrib +p| pin["Disematkan (isi diunduh)"]
    pin -->|attrib -p| local["Tersedia secara lokal"]

Gambar 8: Peralihan dari hanya-online membutuhkan urutan: ambil isi dulu dengan +p, baru -p.

Berikut contoh penilaian di PowerShell. Melihat atribut saja tidak memicu hidrasi, jadi aman dipakai untuk investigasi atau pemeriksaan massal.

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  # Isi tidak seluruhnya ada di lokal
        Pinned             = ($value -band 0x00080000) -ne 0  # Selalu simpan di perangkat ini
        Unpinned           = ($value -band 0x00100000) -ne 0  # Hanya-online
    }
}

# Pemeriksaan massal CSV di bawah folder Dokumen (isinya tidak diunduh).
# Jalur diselesaikan dengan API known folder. Jika nama tampilan «ドキュメント»
# ditulis langsung, jalur itu mungkin tidak ada di lingkungan yang nama folder
# nyatanya bahasa Inggris (Documents) atau pada konfigurasi KFM.
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

Alasan di-cast ke [int] adalah bahwa tipe enumerasi FileAttributes di .NET tidak mendefinisikan nama seperti RECALL_ON_DATA_ACCESS. Operasi bitwise pada angka tetap dapat menilai dengan benar.

5. Jebakan khas aplikasi bisnis

Dari sini inti bahasannya. Transparansi placeholder biasanya nyaman, tetapi jika digabung dengan pola pemrosesan khas aplikasi bisnis, ia muncul dalam enam bentuk berikut.

5.1. Membuka memicu unduhan otomatis — «tidak bisa dibuka» saat luring

Membuka file hanya-online memulai hidrasi di tempat. Untuk file kecil secara online, kecepatannya tidak terasa, tetapi saat OneDrive berhenti, keluar akun, atau dijeda, saat jaringan bermasalah, atau saat file besar, file itu menjadi «ada tetapi tidak bisa dibuka». Kesalahan kadang dikembalikan sebagai kode cloud file seperti ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, «The cloud file provider is not running»), kadang teramati sebagai timeout di sisi aplikasi.⁸

Jebakan berikutnya: pemeriksaan keberadaan setara File.Exists() serta pengambilan atribut dan ukuran berhasil. Pola kesalahannya menjadi «pemeriksaan keberadaan lolos, pembacaan gagal» — sesuatu yang tidak terjelaskan dengan intuisi disk lokal.

flowchart TB
    accTitle: Percabangan akses ke file hanya-online
    accDescr: Pemeriksaan keberadaan serta pengambilan atribut dan ukuran berhasil, tetapi pembacaan isi memulai hidrasi; jika OneDrive berjalan dan jaringan normal file dapat dibaca, jika tidak gagal dengan 0x8007016A atau timeout
    check["Pemeriksaan keberadaan / atribut atau ukuran"] --> ok1["Berhasil"]
    open["Pembacaan isi"] --> hyd["Hidrasi dimulai"]
    hyd --> cond{"OneDrive berjalan dan jaringan normal?"}
    cond -->|Ya| read["Dapat dibaca setelah diunduh"]
    cond -->|Tidak| err["Kesalahan seperti 0x8007016A atau timeout"]

Gambar 9: Pemeriksaan keberadaan dapat berhasil, pembacaan dapat gagal. Hasilnya bergantung pada status OneDrive dan jaringan.

5.2. Proses batch memicu unduhan semua file

Jika pemrosesan batch yang membaca semua file dalam folder, perhitungan hash, pencarian teks penuh, atau pencadangan sendiri diarahkan ke bawah OneDrive, hidrasi dipicu untuk setiap file yang disentuh. Pada folder beberapa GB, pemrosesan tidak hanya menjadi sangat lambat; unduhan menekan disk, dan di PC berkapasitas rendah kekurangan ruang kosong dapat memicu gangguan lain. Kapasitas yang seharusnya dihemat File Sesuai Permintaan hilang hanya dengan satu pemindaian penuh.

Selain itu, jika aplikasi memicu hidrasi tanpa operasi eksplisit pengguna, Windows kadang menampilkan toast dan memberi pengguna pilihan memblokir. Jika diblokir di sini, aplikasi itu terus gagal mengunduh setelahnya (dapat dilepas di «Unduhan file otomatis» pada pengaturan). Ini salah satu penyebab «impor hanya gagal di PC tertentu».⁴

flowchart TB
    accTitle: Alur proses batch yang memicu unduhan semua file
    accDescr: Proses batch ke bawah OneDrive memicu hidrasi semua file yang disentuh, menyebabkan keterlambatan dan tekanan disk; jika pengguna memblokir lewat toast, unduhan terus gagal setelahnya
    scan["Proses batch ke bawah OneDrive"] --> touch["Hidrasi semua file yang disentuh"]
    touch --> cost["Keterlambatan pemrosesan dan tekanan disk"]
    touch --> toast["Toast kadang muncul"]
    toast --> block{"Pengguna memblokir?"}
    block -->|Ya| fail["Unduhan terus gagal setelahnya"]
    block -->|Tidak| cont["Unduhan berlanjut"]

Gambar 10: Proses batch memicu hidrasi semua file; jika diblokir lewat toast, kegagalan berlanjut setelahnya.

5.3. Perilaku salah pada kode yang tidak mengantisipasi atribut

Kode yang tidak mengenal FILE_ATTRIBUTE_OFFLINE atau RECALL_ON_DATA_ACCESS salah berperilaku di tempat yang tidak terduga.

• Karena atribut dinilai dengan kecocokan penuh (attributes == FileAttributes.Archive dan semacamnya), placeholder diperlakukan sebagai «file di luar dugaan» lalu dikecualikan atau dijadikan error
• Penilaian pengecualian alat cadangan/sinkronisasi menafsirkan atribut OFFLINE sebagai «sudah dipindah ke pita» lalu melewatkannya (atau sebaliknya, mengambil semua file padahal seharusnya dikecualikan)
• Pemeriksaan baca-saja atau operasi bit arsip merusak kombinasi atribut

flowchart TB
    accTitle: Pola perilaku salah pada kode yang tidak mengantisipasi atribut
    accDescr: Kode yang tidak mengenal atribut placeholder salah berperilaku lewat pengecualian atau error karena penilaian atribut kecocokan penuh, melewatkan atau mengambil semua file karena salah tafsir OFFLINE, dan merusak kombinasi atribut
    code["Kode yang tidak mengantisipasi atribut"] --> m1["Penilaian kecocokan penuh"]
    code --> m2["Salah tafsir OFFLINE"]
    code --> m3["Operasi atribut merusak kombinasi"]
    m1 --> r1["Dikecualikan atau dijadikan error sebagai di luar dugaan"]
    m2 --> r2["Dilewati atau seluruhnya diambil"]

Gambar 11: Kode yang tidak mengenal atribut OFFLINE atau RECALL salah berperilaku sebagai pengecualian, salah melewati, atau merusak atribut.

Microsoft, dalam panduan untuk pengembang minifilter, menyatakan secara eksplisit agar tidak menerbitkan baca-tulis sembarangan ke file yang membawa RECALL_ON_DATA_ACCESS. Itu dokumen untuk driver kernel, tetapi prinsip «menyentuh isi file yang membawa atribut ini = biaya pengambilan terjadi» berlaku apa adanya pada aplikasi mode pengguna.¹⁰

5.4. Interaksi FileSystemWatcher dan sinkronisasi

Jika folder di bawah OneDrive dipantau dengan FileSystemWatcher, yang sampai bukan hanya operasi pengguna, melainkan juga peristiwa dari aktivitas aplikasi sinkronisasi dalam jumlah besar. Setiap kali perubahan di perangkat lain disinkronkan, dan setiap kali atribut atau ukuran berubah karena hidrasi/dehidrasi, peristiwa Changed dapat terjadi. Lebih jauh, jika rancangannya memantau lalu menulis hasil impor kembali ke folder yang sama, loop tulis → unggah → pembaruan atribut → peristiwa lagi menjadi «badai notifikasi perubahan». Perampingan peristiwa dan rancangan konfirmasi isi dibahas di «Panduan praktis FileSystemWatcher»; di bawah OneDrive kebutuhan itu menjadi lebih tinggi.

flowchart TB
    accTitle: Loop notifikasi perubahan karena pantauan dan penulisan kembali
    accDescr: Jika aplikasi pemantau yang menerima peristiwa perubahan menulis hasil impor kembali ke folder yang sama, unggahan dan pembaruan atribut oleh aplikasi sinkronisasi memicu peristiwa lagi, menjadi loop badai notifikasi perubahan
    ev["Peristiwa perubahan"] --> proc["Aplikasi pemantau mengimpor"]
    proc --> write["Penulisan kembali ke folder yang sama"]
    write --> up["Aplikasi sinkronisasi mengunggah"]
    up --> attr["Atribut atau ukuran diperbarui"]
    attr --> ev
    sync["Sinkronisasi perubahan perangkat lain"] -.-> ev

Gambar 12: Menulis hasil impor kembali ke folder yang sama membuat aktivitas aplikasi sinkronisasi menghasilkan peristiwa lagi, menjadi loop.

5.5. Konflik sinkronisasi saat kunci eksklusif dan file «salinan»

Sementara aplikasi bisnis membuka file dengan kunci eksklusif, aplikasi sinkronisasi tidak dapat mengunggah atau memperbarui file itu. Menaruh aplikasi yang menahan kunci lama (Access .accdb, file data format sendiri, file log, dan semacamnya) di bawah OneDrive membuat kesalahan sinkronisasi menjadi rutin. Sebaliknya, jika file yang sama diedit di beberapa PC, aplikasi sinkronisasi mencoba menyimpan kedua versi dan menghasilkan file duplikat bernama PC atau salinan konflik seperti «〜のコピー». Jika proses impor mengasumsikan «satu folder satu file», file duplikat ini membuatnya salah berperilaku. Dasar rancangan kunci ada di «Pengetahuan dasar pengendalian eksklusif pada integrasi file».

flowchart TB
    accTitle: Masalah sinkronisasi dari kunci eksklusif dan pengeditan multi-PC
    accDescr: Sementara aplikasi membuka dengan kunci eksklusif, aplikasi sinkronisasi tidak dapat memperbarui sehingga kesalahan sinkronisasi menjadi rutin; mengedit file yang sama di beberapa PC menghasilkan salinan konflik dan meruntuhkan asumsi satu folder satu file
    lock["Aplikasi membuka dengan kunci eksklusif"] --> nosync["Tidak dapat disinkronkan; kesalahan sinkronisasi menjadi rutin"]
    multi["File yang sama diedit di beberapa PC"] --> conflict["Salinan konflik dihasilkan"]
    conflict --> dup["File duplikat bernama PC atau «salinan»"]
    dup --> bad["Asumsi satu folder satu file runtuh"]

Gambar 13: Kunci eksklusif membuat kesalahan sinkronisasi rutin; pengeditan di beberapa PC mengundang perilaku salah karena salinan konflik.

5.6. Antivirus dan pengindeks pencarian memicu hidrasi

Yang membaca isi file bukan hanya aplikasi bisnis. Pemindaian penuh perangkat lunak antivirus atau pengindeks pencarian juga memicu hidrasi jika menyentuh isi placeholder. Microsoft Defender dan sejenisnya diimplementasikan agar melewati file yang membawa atribut RECALL_ON_DATA_ACCESS saat pemindaian on-demand, tetapi itu adalah penanganan di sisi produk, dan tidak semua produk keamanan memberi perhatian yang sama. Jika muncul gejala «setiap pemindaian malam, jaringan dan disk mentok», atau «file yang mestinya hanya-online keesokan paginya semuanya sudah berwujud», curigai jalur ini.¹⁴

flowchart TB
    accTitle: Hidrasi yang dipicu produk keamanan atau pengindeks pencarian
    accDescr: Saat pemindaian penuh atau pengindeks pencarian menyentuh isi placeholder, produk yang memperhatikan atribut RECALL melewatkannya, sementara produk yang tidak memperhatikan menghidrasi semua file dan menyebabkan tekanan bandwidth malam atau perwujudan keesokan paginya
    av["Pemindaian penuh atau pengindeks pencarian"] --> care{"Memperhatikan atribut RECALL?"}
    care -->|Produk yang memperhatikan| skip["Melewati placeholder"]
    care -->|Produk yang tidak memperhatikan| hyd["Menyentuh isi lalu hidrasi"]
    hyd --> sym1["Malam hari bandwidth dan disk mentok"]
    hyd --> sym2["Keesokan paginya semua file berwujud"]

Gambar 14: Pemindaian yang tidak memperhatikan atribut memicu hidrasi semua file, dan muncul sebagai beban malam atau perwujudan keesokan paginya.

6. Penanganan sisi pengembangan aplikasi — menghormati placeholder

Kebijakan dasar sebagai pengembang adalah memperlakukan placeholder bukan sebagai «file rusak», melainkan sebagai «file yang punya biaya pengambilan».

• Nilai dari atribut saat enumerasi, dan jangan membuka semena-mena. Pada pemindaian folder, pertama konfirmasi dari atribut (penilaian di bab 4) apakah file hanya-online, lalu buka hanya file yang isinya diperlukan. Untuk pemrosesan «tidak fatal jika tidak ada» seperti pengumpulan log, perhitungan hash, atau pembuatan pratinjau, sediakan pilihan melewati placeholder.

// Nilai yang tidak didefinisikan pada FileAttributes .NET didefinisikan sebagai angka
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} hanya-online, pemrosesan kali ini dilewati");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: Alur menilai dari atribut saat enumerasi lalu membuka
    accDescr: Pada pemindaian folder, atribut dikonfirmasi dulu lewat enumerasi; jika placeholder, dilewati dengan log peringatan, dan hanya file selain itu yang diimpor, sehingga hidrasi sembarangan dihindari
    enum["Konfirmasi atribut lewat enumerasi"] --> ph{"Placeholder?"}
    ph -->|Ya| skip["Lewati dan tulis log peringatan"]
    ph -->|Tidak| imp["Jalankan pemrosesan impor"]
    skip -.-> note["Kebijakan: buka hanya file yang isinya diperlukan"]

Gambar 15: Menilai dari atribut saat enumerasi dan melewati placeholder tanpa membukanya menghindari hidrasi sembarangan.

• Perhatikan bahwa FILE_FLAG_OPEN_NO_RECALL bukan jaminan «tidak mengunduh». Menentukan bendera ini pada CreateFile menunjukkan niat «data yang diperoleh tidak boleh ditulis kembali ke penyimpanan lokal, melainkan dibiarkan di sisi jarak jauh». Namun ini hanya bendera untuk tidak menanamkan data yang diperoleh di lokal; jika isinya dibaca, transfer data itu sendiri tetap terjadi. Jika yang ingin dihindari adalah bandwidth dan latensi, yang paling aman adalah selesai dengan atribut, ukuran, dan cap waktu saja — tidak meminta akses baca (buka dengan hak akses 0, atau pakai metadata hasil enumerasi).⁹

flowchart TB
    accTitle: Efek dan batas FILE_FLAG_OPEN_NO_RECALL
    accDescr: FILE_FLAG_OPEN_NO_RECALL adalah bendera agar data yang diperoleh tidak ditanam di lokal; jika isi dibaca, transfer data tetap terjadi, jadi untuk menghindari transfer yang paling aman adalah selesai dengan metadata seperti atribut
    flag["Buka dengan bendera NO_RECALL"] --> read["Baca isi"]
    read --> transfer["Transfer data tetap terjadi"]
    transfer --> nolocal["Tidak ditanam di lokal"]
    meta["Selesai dengan metadata saja"] --> safe["Tidak ada transfer; paling aman"]

Gambar 16: FILE_FLAG_OPEN_NO_RECALL hanya mencegah penanaman di lokal; untuk menghindari transfer itu sendiri, selesai dengan metadata.

• Sertakan «berada di bawah OneDrive» pada pesan kesalahan. Saat pembacaan gagal, cukup memeriksa apakah jalur sasaran berada di bawah %OneDrive% dan memasukkannya ke pesan sudah memangkas waktu pemilahan di lapangan dan help desk secara signifikan. Idealnya, jika kesalahan cloud file seperti 0x8007016A terdeteksi, arahkan «periksa status OneDrive».
• Jangan taruh folder data aplikasi di bawah OneDrive. Di lingkungan KFM, «Dokumen» juga berada di bawah OneDrive. Pengaturan, basis data, dan file kerja aplikasi taruh di %ProgramData% atau %LocalAppData%, dan jangan pilih desktop atau dokumen sebagai default folder simpan atau folder impor. Pertimbangan di mana menaruh apa dirangkum di «Cara memilih tempat penyimpanan data aplikasi Windows».
• Tentukan perilaku jika pengguna memilih lokasi di bawah OneDrive. Jika aplikasi membiarkan pengguna memilih folder simpan, masukkan ke spesifikasi lebih dulu keputusan rancangan seperti memperingatkan ketika jalur yang dipilih berada di bawah OneDrive (di bawah jalur variabel lingkungan OneDrive/OneDriveCommercial), atau menolak hanya penempatan file kunci dan DB.

7. Penanganan sisi TI — mengendalikan dengan pin dan kebijakan

Dari sisi TI, yang realistis bukan «mematikan seluruh File Sesuai Permintaan», melainkan operasi menjamin isi nyata hanya di tempat yang dibutuhkan bisnis.

• Sematkan folder yang dibaca aplikasi bisnis. Pilih «Selalu simpan di perangkat ini» dari klik kanan Explorer, atau jalankan attrib +p -u <folder> /s /d di skrip kitting (sekaligus menentukan -u agar peralihan ke sematan andal meski ada file yang sudah dijadikan hanya-online). File yang disematkan dijamin isinya di lokal, dan juga keluar dari sasaran konversi otomatis ke hanya-online yang dibahas kemudian.⁷²
• **KFM dan File Sesuai Permintaan dikonfigurasi dengan niat, bukan «ternyata menyala». ** Kebijakan utama (Kebijakan Grup / Intune) adalah sebagai berikut.¹¹¹

• Pahami gerakan Storage Sense. Storage Sense punya kemampuan mengembalikan otomatis file cloud yang tidak dibuka selama sejumlah hari ke hanya-online, dan jumlah hari dapat dikonfigurasi dengan kebijakan (ConfigStorageSenseCloudContentDehydrationThreshold). Nilai default adalah 0 (tidak dikembalikan otomatis), tetapi jika pengguna mengaktifkannya dari layar pengaturan, atau organisasi mengonfigurasinya untuk perangkat berkapasitas kecil, «file yang sampai minggu lalu bisa dibuka kembali ke ikon awan» terjadi sebagai perilaku normal. File yang disematkan berada di luar sasaran, jadi di sini pun «folder bisnis disematkan» berlaku.¹²²

flowchart TB
    accTitle: Percabangan konversi otomatis ke hanya-online oleh Storage Sense
    accDescr: Pada pembebasan otomatis Storage Sense, file yang sudah disematkan berada di luar sasaran dan isinya dipertahankan; file yang tidak disematkan dikembalikan ke hanya-online jika tidak dibuka selama sejumlah hari
    ss["Pembebasan otomatis Storage Sense"] --> pin{"Sudah disematkan?"}
    pin -->|Ya| stay["Di luar sasaran; isi dipertahankan"]
    pin -->|Tidak| old{"Tidak dibuka selama sejumlah hari?"}
    old -->|Ya| dehyd["Kembali ke hanya-online"]
    old -->|Tidak| keep["Isi dipertahankan"]
    ss -.-> def["Default 0: tidak dikembalikan otomatis"]

Gambar 17: Storage Sense mengembalikan file yang tidak dibuka selama sejumlah hari ke hanya-online, tetapi penyematan berada di luar sasaran.

• Nonaktifkan File Sesuai Permintaan hanya setelah menaksir dampaknya. Jika FilesOnDemandEnabled dinonaktifkan, sinkronisasi menjadi unduhan penuh gaya lama, tetapi konsumsi disk dan beban bandwidth sinkronisasi pertama melonjak. Microsoft merekomendasikan tetap mengaktifkannya, dan penonaktifan sebaiknya dipandang sebagai tindakan terbatas setelah memastikan «jumlah data pengguna sasaran kecil» dan «disk masih longgar».¹¹²
• Masukkan ke prosedur dukungan. Memasukkan prosedur pemilahan di bab berikutnya ke templat pertanyaan «file di desktop tidak bisa dibaca» membuat mutu penanganan tetap seragam meski petugas berganti.

8. Prosedur pemilahan — jika ada keluhan «file tidak bisa dibaca»

Saat menerima keluhan, konfirmasi dari atas ke bawah.

Tindakan darurat adalah klik kanan folder sasaran lalu pilih «Selalu simpan di perangkat ini» (atau attrib +p /s /d). Dengan itu isi lokal lengkap dan pekerjaan dapat dilanjutkan. Setelah itu, putuskan apakah penyebab esensial ada di bab 6 (sisi aplikasi) atau bab 7 (sisi TI) sebagai penanganan permanen.

flowchart TB
    accTitle: Alur dari tindakan darurat ke penanganan permanen
    accDescr: Sebagai tindakan darurat, mengatur folder sasaran ke Selalu simpan di perangkat ini melengkapi isi lokal dan pekerjaan dapat dilanjutkan; setelah itu diputuskan apakah penyebab esensial di sisi aplikasi atau sisi TI, lalu maju ke penanganan permanen
    aid["Tindakan darurat: sematkan"] --> restore["Isi lokal lengkap"]
    restore --> resume["Pekerjaan dilanjutkan"]
    resume --> judge{"Penyebab esensialnya?"}
    judge -->|Sisi aplikasi| dev["Ke penanganan bab 6"]
    judge -->|Sisi TI| ops["Ke penanganan bab 7"]

Gambar 18: Tindakan darurat menyematkan agar isi lengkap dan pekerjaan dilanjutkan; penanganan permanen maju setelah memutus sisi aplikasi atau sisi TI.

Jika setelah konfirmasi sampai di sini «jalur bukan di bawah OneDrive» dan «bukan placeholder», lanjut ke penyebab klasik jalur lain seperti folder berbagi atau panjang jalur. «Jebakan network drive dan jalur UNC» dan «MAX_PATH serta jebakan jalur dan nama file Windows» menjadi peta kelanjutannya.

9. Ringkasan

• Karena KFM, isi nyata Desktop, Dokumen, dan Gambar mungkin sudah pindah ke bawah C:\Users\<nama>\OneDrive\. Aplikasi yang mengasumsikan jalur tetap patah di sini. Langkah pertama adalah menyelesaikannya dengan API known folder.
• File Sesuai Permintaan menyala secara default, dan placeholder tanpa isi lokal biasa ada. Placeholder adalah titik reparse Cloud Files API (cldflt.sys), dan membukanya memicu hidrasi otomatis.
• Keadaan dapat dinilai dari atribut file (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED), dan attrib menampilkannya sebagai O, P, U. Memeriksa atribut saja tidak memicu unduhan.
• Kecelakaan aplikasi bisnis muncul sebagai kegagalan hidrasi saat luring, unduhan penuh karena proses batch, kode yang tidak mengantisipasi atribut, interaksi FileSystemWatcher dan sinkronisasi, konflik kunci eksklusif dan sinkronisasi, serta hidrasi yang dipicu produk keamanan.
• Di sisi aplikasi, dasarnya «nilai dari atribut dan jangan membuka semena-mena», «jangan taruh folder data di bawah OneDrive», dan «saat error sampaikan bahwa berada di bawah OneDrive».
• Di sisi TI, «penyematan folder bisnis» dan «kendali kebijakan KFM, File Sesuai Permintaan, dan Storage Sense» membentuk keadaan yang disengaja.
• Pemilahan dapat dijalankan secara mekanis dalam urutan jalur → attrib → OneDrive berjalan → jaringan → ruang kosong → catatan.

Lain kali, jika ada keluhan «file ada tetapi tidak bisa dibaca», tanyakan ulang dulu seperti ini.

Apakah file itu benar-benar ada di disk lokal? Atau yang ada di situ hanya tampilan dari cloud?

Artikel terkait

• Kedalaman I/O Windows (bagian 5) — Struktur internal NTFS: memahami sistem file dari MFT
• Panduan praktis FileSystemWatcher - penanganan terlewat dan duplikat
• Jebakan network drive dan jalur UNC — praktik aplikasi bisnis yang menangani file server (folder berbagi)
• Pengetahuan dasar pengendalian eksklusif pada integrasi file - praktik terbaik file lock dan claim atomik
• Cara memilih tempat penyimpanan data aplikasi Windows — tabel keputusan SQLite / JSON / registri / Access
• MAX_PATH serta jebakan jalur dan nama file Windows — batas 260 karakter, nama terpesan, titik di akhir, huruf besar-kecil

Area konsultasi terkait

Di Komura Soft (合同会社小村ソフト), kami menangani investigasi gangguan aplikasi bisnis terkait OneDrive dan penyimpanan cloud seperti «proses impor yang selama ini berjalan tidak jalan setelah PC diganti» atau «file hanya tidak bisa dibaca di PC tertentu», rancangan dan perbaikan pemrosesan file serta pemantauan yang mengandaikan placeholder, serta tinjauan rancangan folder simpan di lingkungan KFM dan File Sesuai Permintaan. Boleh mulai dari pemilahan gejala; silakan berkonsultasi.

• Pengembangan aplikasi Windows
• Investigasi gangguan dan analisis penyebab
• Konsultasi teknis dan tinjauan rancangan
• Hubungi kami

Tautan rujukan

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Aplikasi bisnis tidak bisa membaca CSV yang ditaruh di desktop dan mengatakan «file tidak ditemukan». Mengapa?

Dalam banyak kasus, folder desktop sendiri sudah dipindahkan ke bawah C:\Users\<nama>\OneDrive\Desktop oleh Known Folder Move (KFM) OneDrive, atau file sudah menjadi placeholder hanya-online. Jika aplikasi mengasumsikan jalur tetap seperti C:\Users\<nama>\Desktop, file tidak ditemukan setelah pemindahan. Bahkan jika jalurnya benar, file hanya-online bisa gagal dibuka saat OneDrive berhenti atau jaringan bermasalah. Pertama, pastikan apakah jalur sasaran berada di bawah OneDrive, lalu periksa dengan perintah attrib apakah U (hanya-online) terpasang. Sebagai tindakan darurat, isi lokal dapat diamankan lewat «Selalu simpan di perangkat ini» pada menu klik kanan.

Bisakah program menentukan apakah sebuah file hanya-online?

Bisa. Placeholder hanya-online membawa atribut seperti FILE_ATTRIBUTE_OFFLINE dan FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000), jadi keadaan dapat dinilai dari atribut file tanpa mengunduh isinya. Mengambil atribut atau mengenumerasi folder tidak memicu hidrasi (unduh). Di .NET ada nilai yang tidak didefinisikan pada FileAttributes, jadi nilai itu di-cast ke bilangan bulat lalu diuji dengan operasi bitwise. Jika benar-benar perlu membuka tanpa membaca isi, sarana seperti FILE_FLAG_OPEN_NO_RECALL pada CreateFile juga tersedia.

Apakah menonaktifkan File Sesuai Permintaan menyelesaikan masalah?

Perlakukan penonaktifan sebagai pilihan terakhir. Jika dinonaktifkan, semua file dalam lingkup sinkronisasi diunduh ke lokal, sehingga kapasitas disk dan beban jaringan sinkronisasi pertama menjadi besar, dan Microsoft juga merekomendasikan tetap mengaktifkannya. Dalam praktik, lebih fleksibel hanya menyematkan folder yang dibaca aplikasi bisnis dengan «Selalu simpan di perangkat ini». Secara lebih mendasar, yang paling andal adalah merancang ulang agar folder data dan folder impor aplikasi tidak berada di bawah pengelolaan OneDrive.

Sudah diatur «Selalu simpan di perangkat ini», tetapi ada file yang tanpa disadari kembali ke ikon awan. Mengapa?

Pertama, pastikan dengan perintah attrib bahwa file itu benar-benar memiliki pin (atribut P). File yang disematkan berada di luar konversi otomatis ke hanya-online oleh Storage Sense, tetapi file «tersedia secara lokal» yang hanya dibuka tanpa disematkan dapat dikembalikan ke hanya-online setelah jangka waktu tertentu, tergantung pengaturan dan kebijakan Storage Sense. Selain itu, operasi «Kosongkan ruang» oleh pengguna sendiri, dan kebijakan yang membuat file situs tim hanya-online (DehydrateSyncedTeamSites), juga mengembalikan ikon awan. Folder yang secara bisnis harus tetap lokal sebaiknya dioperasikan dengan penyematan per folder.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.