OneDrive "File Sesuai Permintaan" dan aplikasi bisnis — asumsi yang dipecah placeholder dan cara menghadapinya

“Aplikasi bisnis tidak dapat membaca CSV yang saya simpan di desktop.” “Impor yang dulu berjalan gagal dengan ‘file tidak ditemukan’ setelah penggantian PC.” “Explorer menampilkan file, tetapi membukanya dari aplikasi error.” — Beberapa tahun terakhir, jenis konsultasi pelanggan ini menjadi langganan.

Saat diselidiki, penyebabnya sering bukan bug aplikasi melainkan “pencadangan otomatis Desktop dan Dokumen” OneDrive (Known Folder Move, KFM) dan “File Sesuai Permintaan”. Desktop yang nyata telah pindah ke C:\Users\<nama>\OneDrive\Desktop, dan sebagian file yang Anda lihat di sana adalah “placeholder” tanpa isi lokal. Pengguna dan IT terus memakai PC tanpa menyadari perubahan ini.

Dengan kata lain, asumsi implisit aplikasi bisnis bahwa “file ada di disk lokal” telah, tanpa siapa pun memutuskannya, diganti oleh asumsi bahwa “file ada di cloud, dan secara lokal hanya ada tampilan”. Ditujukan kepada staf IT usaha kecil-menengah dan pengembang aplikasi Windows, artikel ini merapikan, dari sumber primer Microsoft Learn, cara kerja placeholder, cara menilai keadaan dari atribut file, jebakan khas yang diinjak aplikasi bisnis, apa yang bisa dilakukan sisi pengembangan dan sisi IT, serta prosedur triase ketika Anda ditanya “file tidak mau terbuka”.

flowchart TB
    accTitle: Penggantian asumsi implisit aplikasi bisnis
    accDescr: Asumsi implisit aplikasi bisnis bahwa file ada di disk lokal telah, tanpa siapa pun memutuskannya, diganti oleh asumsi bahwa isi nyata ada di cloud dan secara lokal hanya ada tampilan
    before["Asumsi implisit tradisional"] --> b1["Isi nyata di disk lokal"]
    after["Asumsi yang diganti"] --> a1["Isi nyata ada di cloud"]
    a1 --> a2["Secara lokal hanya ada tampilan"]
    a2 -.-> note["Sebuah placeholder"]

Gambar 1: Asumsi bahwa “isi nyata ada di lokal” telah, tanpa siapa pun memutuskannya, diganti oleh “isi nyata ada di cloud; secara lokal hanya ada tampilan”.

1. Kesimpulan dulu

• Desktop, Dokumen, dan Gambar mungkin telah dipindahkan ke bawah C:\Users\<nama>\OneDrive\ oleh KFM. Ini cenderung dinyalakan 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-daring” tanpa isi lokal.²³
• Identitas nyata placeholder adalah titik reparse yang dikelola Cloud Files API (minifilter cldflt.sys). Ia tampak seperti 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 menyebabkan unduhan.⁵⁶⁷
• Kecelakaan khas aplikasi bisnis adalah kombinasi “tidak mau terbuka”, “lambat”, “atribut salah dinilai”, “badai peristiwa pantauan”, dan “konflik dengan sinkronisasi”. Luring atau saat OneDrive berhenti, hidrasi gagal, dan proses batch memicu unduhan setiap file.⁴⁸
• Respons 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.⁹¹⁰
• Respons sisi IT adalah “beroperasi dengan pin” dan “kendali lewat kebijakan”. Jamin isi nyata folder bisnis dengan “Selalu simpan di perangkat ini”, dan konfigurasi KFM serta File Sesuai Permintaan dengan sengaja lewat Kebijakan Grup / Intune. Jangan lupa Storage Sense juga dapat “mengembalikan file yang tak terpakai ke hanya-daring”.¹¹¹²

Dalam satu kalimat: “file yang terlihat di Explorer” dan “file yang punya isi nyata di disk lokal” bukan lagi hal yang sama.

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 bernama Known Folder Move (KFM). Di layar pengaturan ia ditampilkan sebagai “Cadangan”, “Cadangkan folder penting”, dan semacamnya; ketika menyala, Desktop, Dokumen, dan Gambar yang nyata dipindahkan (dialihkan) ke bawah folder OneDrive.¹

Pada penyiapan awal (OOBE) PC baru, masuk dengan akun Microsoft atau akun kerja secara luas menampilkan cadangan folder sebagai usulan default, dan meneruskan apa adanya menyalakannya. Organisasi juga dapat menerapkannya massal tanpa menanyakan apa pun kepada pengguna, dengan kebijakan “Pindahkan folder dikenal Windows ke OneDrive secara senyap” (KFMSilentOptIn).¹¹¹

flowchart TB
    accTitle: Dua jalur KFM dinyalakan
    accDescr: Masuk dengan akun saat penyiapan awal PC baru menampilkan cadangan folder sebagai usulan default dan meneruskan apa adanya menyalakannya; di organisasi kebijakan KFMSilentOptIn menerapkannya massal tanpa menanya pengguna
    oobe["Penyiapan awal PC baru"] --> signin["Masuk dengan akun"]
    signin --> prompt["Cadangan diusulkan secara default"]
    prompt --> on1["Meneruskan apa adanya menyalakannya"]
    org["Kebijakan organisasi"] --> silent["KFMSilentOptIn"]
    silent --> on2["Diterapkan massal tanpa menanya"]
    on1 --> kfm["KFM menyala"]
    on2 --> kfm

Gambar 2: KFM dinyalakan tanpa siapa pun menyadari, baik oleh usulan default saat penyiapan awal maupun oleh kebijakan penerapan senyap organisasi.

Bagian yang canggung adalah tampilan di Explorer hampir tidak berubah. API folder dikenal shell (SHGetKnownFolderPath dan Environment.GetFolderPath .NET) mengembalikan jalur yang benar setelah pindah, jadi aplikasi yang sopan tetap jalan. Yang patah adalah aplikasi yang menanam jalur tetap seperti C:\Users\%USERNAME%\Desktop di file pengaturan atau di kode. Pola khas impor yang gagal dengan “file tidak ditemukan” setelah penggantian PC adalah ini.

flowchart TB
    accTitle: Perilaku resolusi jalur aplikasi setelah KFM
    accDescr: Setelah KFM memindahkan Desktop nyata dan folder serupa ke bawah OneDrive, aplikasi yang memakai API folder dikenal tetap jalan dengan jalur benar setelah pindah, tetapi aplikasi yang menanam jalur tetap gagal dengan file tidak ditemukan
    kfm["KFM dinyalakan"] --> move["Desktop nyata dan serupa pindah ke bawah OneDrive"]
    move --> how{"Bagaimana aplikasi meresolusi jalur?"}
    how -->|API folder dikenal| ok["Mendapat jalur benar setelah pindah dan tetap jalan"]
    how -->|Jalur tetap yang di-hardcode| ng["File tidak ditemukan"]

Gambar 3: Setelah KFM, aplikasi yang memakai API folder dikenal tetap jalan, tetapi aplikasi yang meng-hardcode jalur tetap patah di sini.

2.2. File Sesuai Permintaan — terlihat, tetapi tanpa isi nyata

Jejak lain adalah File Sesuai Permintaan. Di lingkungan yang menyala, setiap file di OneDrive terlihat di Explorer, tetapi isi tidak diunduh sampai file dibuka. Fitur ini menyala secara default di aplikasi sinkronisasi saat ini, dan Microsoft juga merekomendasikan membiarkannya menyala.²³

Keadaan dapat dibaca dari ikon status di Explorer.¹³

Yang penting di sini adalah keadaan tengah. File yang pernah dibuka dan kini punya isi lokal dapat kembali ke hanya-daring melalui tindakan “Kosongkan ruang” pengguna atau melalui Storage Sense, yang dibahas kemudian. Itu salah satu penyebab kegagalan yang sulit direproduksi jenis “bulan lalu masih jalan”.³¹²

stateDiagram-v2
    accTitle: Tiga keadaan File Sesuai Permintaan dan transisinya
    accDescr: File hanya-daring menjadi tersedia secara lokal saat dibuka, tetapi Kosongkan ruang atau Storage Sense dapat mengembalikannya ke hanya-daring, dan hanya file yang disematkan yang di luar pembebasan otomatis
    s1: Hanya-daring (tanda awan)
    s2: Tersedia secara lokal
    s3: Disematkan (Selalu simpan di perangkat ini)
    s1 --> s2: Buka (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 otomatis kembali ke hanya-daring; pin berada di luar itu.

3. Identitas nyata placeholder — Cloud Files API dan titik reparse

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

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

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

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

Mendengar “titik reparse” membuat Anda khawatir tentang kompatibilitas dengan kode lama yang “memperlakukan titik reparse secara khusus jika mendeteksinya”, tetapi demi kompatibilitas Cloud Files API menyembunyikan fakta bahwa itu titik reparse dari semua orang kecuali mesin sinkronisasi dan proses di bawah %systemroot%. Dari aplikasi biasa ia tampak seperti “file biasa yang hanya agak lambat dibuka”. Transparansi yang teliti itu, bersamaan dengan nyaman, juga alasan “aplikasi mendapat asumsinya dipecah tanpa sadar”.⁴ Mekanisme titik reparse sendiri dijelaskan di “NTFS Internals”.

flowchart TB
    accTitle: Menyembunyikan titik reparse, dan perbedaan tampilan
    accDescr: Identitas nyata placeholder adalah titik reparse, tetapi Cloud Files API menyembunyikannya dari proses selain mesin sinkronisasi, jadi dari aplikasi biasa ia tampak seperti file biasa yang hanya agak lambat dibuka
    ph["Placeholder (titik reparse)"] --> who{"Proses mana yang membukanya?"}
    who -->|Mesin sinkronisasi dan serupa| raw["Terlihat sebagai titik reparse"]
    who -->|Aplikasi lain mana pun| plain["Tampak seperti file biasa"]
    plain -.-> note["Tampak hanya agak lambat dibuka"]

Gambar 6: Fakta bahwa itu titik reparse disembunyikan dari semua orang kecuali mesin sinkronisasi, dan bagi aplikasi biasa ia tampak seperti file biasa.

Di properti Explorer, placeholder punya tampilan khas bahwa “Ukuran” menampilkan ukuran asli, sementara “Ukuran di disk” hampir 0. Asumsi “punya ukuran, jadi pasti punya isi nyata” tidak berlaku di sini.

flowchart TB
    accTitle: Tampilan placeholder di properti
    accDescr: Di properti Explorer placeholder menampilkan ukuran asli sebagai Ukuran sementara Ukuran di disk hampir 0, jadi asumsi bahwa ia punya ukuran dan karena itu harus punya isi nyata tidak berlaku
    prop["Properti placeholder"] --> size["Ukuran adalah ukuran asli"]
    prop --> disk["Ukuran di disk hampir 0"]
    size -.-> trap["Asumsi bahwa harus ada isi nyata"]
    disk -.-> truth["Tidak ada isi lokal"]

Gambar 7: Placeholder menampilkan ukuran asli sebagai “Ukuran” sementara “Ukuran di disk” hampir 0.

4. Atribut file memberi tahu keadaan

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

Perintah attrib di prompt perintah dapat menampilkan dan menetapkan ini sebagai satu huruf. O adalah atribut luring, P disematkan, U dilepas sematannya.⁶ Korespondensi dengan keadaan File Sesuai Permintaan OneDrive disusun di dokumentasi Microsoft sebagai berikut.⁷

Satu peringatan. Mengganti keadaan punya urutan. Ketika Anda ingin file hanya-daring (U) menjadi “tersedia secara lokal”, menjalankan -p saja meninggalkan U terpasang dan isi nyata tidak diambil. Dokumentasi Microsoft juga menunjukkan prosedur pertama melakukan +p (selalu tersedia) untuk mengunduh isi nyata lalu -p.⁷ Dalam skrip yang harus mengganti keadaan yang ada secara andal, lebih aman menghapus atribut lawan pada saat yang sama, seperti attrib +p -u.

flowchart TB
    accTitle: Urutan beralih dari hanya-daring ke tersedia secara lokal
    accDescr: Menjalankan attrib -p saja pada file hanya-daring meninggalkan atribut U dan isi nyata tidak diambil; Anda perlu prosedur pertama mengunduh isi nyata dengan attrib +p lalu -p
    u["Hanya-daring (U)"] -->|hanya attrib -p| stay["Tetap U; isi nyata tidak diambil"]
    u -->|attrib +p| pin["Disematkan (unduh isi nyata)"]
    pin -->|attrib -p| local["Tersedia secara lokal"]

Gambar 8: Beralih dari hanya-daring membutuhkan urutan pertama mengambil isi nyata dengan +p lalu -p.

Contoh penilaian di PowerShell. Melihat atribut saja tidak menyebabkan hidrasi, jadi Anda dapat memakainya dengan yakin untuk investigasi dan 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  # Tidak semua isi lokal
        Pinned             = ($value -band 0x00080000) -ne 0  # Selalu simpan di perangkat ini
        Unpinned           = ($value -band 0x00100000) -ne 0  # Hanya-daring
    }
}

# Periksa massal CSV di bawah folder Dokumen (isi tidak diunduh).
# Resolusikan jalur dengan API folder dikenal. Meng-hardcode nama tampilan
# "Documents" dapat menjadi jalur yang tidak ada tergantung nama folder nyata
# (Documents vs. nama terlokalkan) dan konfigurasi KFM
Get-ChildItem ([Environment]::GetFolderPath('MyDocuments')) -Recurse -Filter *.csv |
    ForEach-Object { Test-CloudPlaceholder $_.FullName } |
    Where-Object RecallOnDataAccess |
    Format-Table -AutoSize

Cast ke [int] karena enumerasi FileAttributes .NET tidak mendefinisikan nama seperti RECALL_ON_DATA_ACCESS. Operasi bitwise pada nilai numerik dapat menilai tanpa kesulitan.

5. Jebakan yang diinjak aplikasi bisnis

Ini subjek utamanya. Transparansi placeholder nyaman hampir sepanjang waktu, tetapi digabung dengan pola pemrosesan khas aplikasi bisnis ia muncul dalam enam bentuk berikut.

5.1. Membuka otomatis memulai unduhan — “tidak mau terbuka” saat luring

Membuka file hanya-daring memulai hidrasi di tempat. Daring, dengan file kecil, begitu cepat Anda tidak menyadari, tetapi ketika OneDrive berhenti, keluar, atau dijeda, ketika jaringan tidak sehat, atau ketika file besar, ia menjadi “file yang ada tetapi tidak mau terbuka”. Kesalahan dapat kembali sebagai kode keluarga cloud-file seperti ERROR_CLOUD_FILE_PROVIDER_NOT_RUNNING (0x8007016A, “The cloud file provider is not running”), atau diamati sebagai batas waktu di sisi aplikasi.⁸

Jebakan lebih lanjut adalah bahwa pemeriksaan keberadaan setara File.Exists(), dan mengambil atribut atau ukuran, berhasil. Anda mendapat pola kesalahan yang tidak dapat dijelaskan intuisi disk lokal: “pemeriksaan keberadaan lolos, tetapi pembacaan gagal”.

flowchart TB
    accTitle: Cabang saat mengakses file hanya-daring
    accDescr: Pemeriksaan keberadaan dan pengambilan atribut serta ukuran berhasil, tetapi membaca isi memulai hidrasi; jika OneDrive berjalan dan jaringan sehat Anda dapat membaca setelah unduhan, jika tidak Anda gagal dengan kesalahan seperti 0x8007016A atau batas waktu
    check["Pemeriksaan keberadaan, atau mengambil atribut atau ukuran"] --> ok1["Berhasil"]
    open["Membaca isi"] --> hyd["Hidrasi dimulai"]
    hyd --> cond{"OneDrive berjalan dan jaringan sehat?"}
    cond -->|Ya| read["Dapat dibaca setelah unduhan"]
    cond -->|Tidak| err["Kesalahan seperti 0x8007016A, atau batas waktu"]

Gambar 9: Pemeriksaan keberadaan dapat berhasil sementara pembacaan gagal. Berhasil atau gagal tergantung apakah OneDrive berjalan dan pada jaringan.

5.2. Proses batch memicu unduhan setiap file

Arahkan batch yang membaca setiap file di folder, perhitungan hash, pencarian teks penuh, atau cadangan buatan sendiri ke pohon di bawah OneDrive dan hidrasi setiap file yang Anda sentuh dipicu. Untuk folder beberapa GB, proses menjadi sangat lambat, unduhan juga mengisi disk, dan di PC berkapasitas rendah kekurangan ruang bebas mengundang kegagalan lain. Kapasitas yang seharusnya dihemat File Sesuai Permintaan hilang dalam satu pemindaian penuh.

Juga, jika aplikasi menyebabkan hidrasi tanpa tindakan pengguna yang eksplisit, Windows dapat menampilkan toast dan memberi pengguna pilihan untuk memblokir. Sekali diblokir, aplikasi itu terus gagal mengunduh setelahnya (dapat diangkat dengan “Unduhan file otomatis” di Pengaturan). Itu salah satu penyebab “impor gagal hanya di PC tertentu”.⁴

flowchart TB
    accTitle: Bagaimana batch memicu unduhan setiap file
    accDescr: Batch di bawah OneDrive memicu hidrasi setiap file yang disentuhnya, menyebabkan penundaan pemrosesan dan tekanan disk, dan jika pengguna memblokir di toast, unduhan terus gagal setelahnya
    scan["Batch di bawah OneDrive"] --> touch["Hidrasi setiap file yang disentuh"]
    touch --> cost["Penundaan pemrosesan dan tekanan disk"]
    touch --> toast["Toast dapat muncul"]
    toast --> block{"Apakah pengguna memblokir?"}
    block -->|Ya| fail["Unduhan terus gagal setelahnya"]
    block -->|Tidak| cont["Unduhan berlanjut"]

Gambar 10: Batch memicu hidrasi setiap file, dan jika diblokir di toast, kegagalan berlanjut setelahnya.

5.3. Perilaku salah kode yang tidak mengharapkan atribut

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

• Atribut diuji kesamaan persis (attributes == FileAttributes.Archive dan semacamnya), jadi placeholder dikecualikan atau diperlakukan sebagai kesalahan sebagai “file tak terduga”
• Keputusan pengecualian di alat cadangan atau sinkronisasi menafsirkan atribut OFFLINE sebagai “sudah dikirim ke pita” dan melewati (atau, sebaliknya, mengambil setiap file yang seharusnya dikecualikan)
• Pemeriksaan baca-saja atau operasi bit arsip merusak kombinasi atribut

flowchart TB
    accTitle: Pola perilaku salah kode yang tidak mengharapkan atribut
    accDescr: Kode yang tidak mengenal atribut placeholder berperilaku salah sebagai pengecualian atau penanganan kesalahan dari uji kesamaan persis, lewati atau ambil penuh dari salah tafsir OFFLINE, atau merusak kombinasi atribut
    code["Kode yang tidak mengharapkan atribut"] --> m1["Uji kesamaan persis"]
    code --> m2["Salah menafsirkan OFFLINE"]
    code --> m3["Operasi atribut merusak kombinasi"]
    m1 --> r1["Dikecualikan atau error sebagai tak terduga"]
    m2 --> r2["Lewati, atau pengambilan penuh"]

Gambar 11: Kode yang tidak mengenal OFFLINE atau atribut keluarga RECALL berperilaku salah sebagai pengecualian, lewati yang salah, atau perusakan atribut.

Panduan Microsoft untuk pengembang minifilter menyatakan dengan jelas bahwa Anda tidak boleh mengeluarkan baca atau tulis yang ceroboh ke file yang punya RECALL_ON_DATA_ACCESS. Dokumen ditujukan ke driver kernel, tetapi prinsip “menyentuh isi file dengan atribut ini = biaya pengambilan terjadi” berlaku apa adanya ke aplikasi mode pengguna.¹⁰

5.4. Interaksi FileSystemWatcher dan sinkronisasi

Pantau folder di bawah OneDrive dengan FileSystemWatcher dan Anda mendapat bukan hanya tindakan pengguna tetapi juga sejumlah besar peristiwa dari aktivitas aplikasi sinkronisasi. Setiap kali perubahan di perangkat lain disinkronkan, dan setiap kali hidrasi atau dehidrasi mengubah atribut atau ukuran, peristiwa Changed dapat menyala. Lebih jauh, rancangan yang menulis hasil pantau-dan-impor kembali ke folder yang sama menjadi “badai pemberitahuan perubahan” dalam putaran tulis → unggah → pembaruan atribut → peristiwa lain. Penipisan peristiwa dan rancangan pemeriksaan isi nyata dibahas di “A Practical Guide to FileSystemWatcher”, tetapi di bawah OneDrive kebutuhannya satu tingkat lebih tinggi.

flowchart TB
    accTitle: Putaran pemberitahuan perubahan dari memantau dan menulis kembali
    accDescr: Jika aplikasi pemantau yang menerima peristiwa perubahan menulis hasil impor kembali ke folder yang sama, unggahan dan pembaruan atribut aplikasi sinkronisasi menyalakan peristiwa lain, dan itu menjadi putaran — badai pemberitahuan perubahan
    ev["Peristiwa perubahan"] --> proc["Aplikasi pemantau mengimpor"]
    proc --> write["Tulis kembali ke folder yang sama"]
    write --> up["Aplikasi sinkronisasi mengunggah"]
    up --> attr["Atribut atau ukuran diperbarui"]
    attr --> ev
    sync["Sinkronisasi perubahan dari perangkat lain"] -.-> ev

Gambar 12: Menulis hasil impor kembali ke folder yang sama menjadi putaran di mana aktivitas aplikasi sinkronisasi menghasilkan peristiwa lain.

5.5. Konflik sinkronisasi selama kunci eksklusif, dan file “Salinan”

Sementara aplikasi bisnis membuka file dengan kunci eksklusif, aplikasi sinkronisasi tidak dapat mengunggah maupun memperbarui file itu. Menaruh aplikasi yang menahan kunci lama (Access .accdb, file data format buatan sendiri, file log, dan semacamnya) di bawah OneDrive membuat kesalahan sinkronisasi menjadi keadaan normal. Sebaliknya, ketika file yang sama diedit di beberapa PC, aplikasi sinkronisasi mencoba menjaga kedua edisi dan menghasilkan file duplikat dengan nama PC atau salinan konflik seperti “— salinan”. Impor yang mengasumsikan “satu folder, satu file” berperilaku salah pada duplikat ini. Dasar rancangan kunci ada di “Mutual Exclusion Fundamentals for File-Based Integration”.

flowchart TB
    accTitle: Masalah sinkronisasi akibat kunci eksklusif dan pengeditan multi-PC
    accDescr: Sementara aplikasi membuka file dengan kunci eksklusif aplikasi sinkronisasi tidak dapat memperbarui dan kesalahan sinkronisasi menjadi keadaan normal; mengedit file yang sama di beberapa PC menghasilkan salinan konflik dan asumsi satu-folder-satu-file runtuh
    lock["Aplikasi membuka dengan kunci eksklusif"] --> nosync["Tidak dapat menyinkronkan; kesalahan menjadi normal"]
    multi["File yang sama diedit di beberapa PC"] --> conflict["Salinan konflik dihasilkan"]
    conflict --> dup["Duplikat dengan nama PC atau salinan"]
    dup --> bad["Asumsi satu-folder-satu-file runtuh"]

Gambar 13: Kunci eksklusif membuat kesalahan sinkronisasi menjadi keadaan normal, dan pengeditan di beberapa PC mengundang perilaku salah dari salinan konflik.

5.6. Antivirus dan pengindeks pencarian memicu hidrasi

Bukan hanya aplikasi bisnis yang membaca isi file. Pemindaian penuh perangkat lunak antivirus, dan pengindeks pencarian, juga memicu hidrasi jika mereka menyentuh isi placeholder. Microsoft Defender dan produk serupa melewati file yang punya atribut RECALL_ON_DATA_ACCESS saat pemindaian sesuai permintaan, tetapi itu respons sisi produk, dan Anda tidak dapat mengasumsikan setiap produk keamanan akan menunjukkan kehati-hatian yang sama. Jika Anda melihat gejala seperti “jaringan dan disk mentok setiap malam saat pemindaian” atau “file yang seharusnya hanya-daring semuanya sudah terwujud pagi hari”, curigai jalur ini.¹⁴

flowchart TB
    accTitle: Hidrasi yang dipicu produk keamanan atau pengindeks pencarian
    accDescr: Ketika pemindaian penuh atau pengindeks pencarian menyentuh isi placeholder, produk yang menghormati atribut RECALL melewati, tetapi produk yang tidak menghormatinya menghidrasi setiap file dan menyebabkan tekanan bandwidth malam atau perwujudan pagi
    av["Pemindaian penuh atau pengindeks pencarian"] --> care{"Menghormati atribut RECALL?"}
    care -->|Produk yang menghormatinya| skip["Melewati placeholder"]
    care -->|Produk yang tidak| hyd["Menyentuh isi dan menghidrasi"]
    hyd --> sym1["Bandwidth dan disk mentok di malam hari"]
    hyd --> sym2["Pagi hari file semuanya sudah terwujud"]

Gambar 14: Pemindaian yang tidak menghormati atribut memicu hidrasi setiap file, dan muncul sebagai beban malam atau perwujudan pagi.

6. Respons pengembangan aplikasi — hormati 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 buka semena-mena. Dalam pemindaian folder, pertama pastikan dari atribut (penilaian Bab 4) apakah ia hanya-daring, dan buka hanya file yang isinya Anda butuhkan. Beri pemrosesan yang “tidak fatal jika hilang” — pengumpulan log, perhitungan hash, pembuatan pratinjau — opsi untuk melewati placeholder.

// Definisikan sebagai angka nilai yang FileAttributes di .NET tidak definisikan
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-daring; dilewati kali ini");
        continue;
    }
    Import(file.FullName);
}

flowchart TB
    accTitle: Jalur menilai dari atribut saat enumerasi lalu membuka
    accDescr: Dalam pemindaian folder, pertama pastikan atribut saat enumerasi; jika placeholder, lewati dan tinggalkan log peringatan, dan jalankan impor hanya pada file lain, agar hidrasi ceroboh dihindari
    enum["Pastikan atribut saat enumerasi"] --> ph{"Placeholder?"}
    ph -->|Ya| skip["Lewati dan tinggalkan log peringatan"]
    ph -->|Tidak| imp["Jalankan impor"]
    skip -.-> note["Kebijakan membuka hanya file yang isinya dibutuhkan"]

Gambar 15: Nilai dari atribut saat enumerasi dan lewati placeholder tanpa membukanya, agar hidrasi ceroboh dihindari.

• Catat bahwa FILE_FLAG_OPEN_NO_RECALL bukan jaminan “jangan unduh”. Menentukan bendera ini pada CreateFile dapat menunjukkan niat bahwa “data yang diperoleh harus ditinggal di sisi jarak jauh dan tidak ditulis kembali ke penyimpanan lokal”. Namun itu bendera hanya untuk tidak membuat data yang diperoleh residensial secara lokal; jika Anda membaca isi, transfer data itu sendiri tetap terjadi. Jika Anda ingin menghindari bandwidth dan latensi itu sendiri, selesai dengan atribut, ukuran, dan cap waktu saja — jangan minta akses baca (buka dengan hak akses 0, pakai metadata dari hasil enumerasi). Itu yang paling aman.⁹

flowchart TB
    accTitle: Efek dan batas FILE_FLAG_OPEN_NO_RECALL
    accDescr: FILE_FLAG_OPEN_NO_RECALL adalah bendera untuk tidak membuat data yang diperoleh residensial secara lokal; jika Anda membaca isi transfer data itu sendiri tetap terjadi, jadi jika ingin menghindari transfer yang paling aman adalah selesai dengan metadata seperti atribut
    flag["Buka dengan bendera NO_RECALL"] --> read["Baca isi"]
    read --> transfer["Transfer data terjadi"]
    transfer --> nolocal["Tidak menjadi residensial secara lokal"]
    meta["Selesai dengan metadata saja"] --> safe["Tidak ada transfer; paling aman"]

Gambar 16: FILE_FLAG_OPEN_NO_RECALL hanya mencegah menjadi residensial secara lokal; jika ingin menghindari transfer itu sendiri, selesai dengan metadata saja.

• Taruh “ini di bawah OneDrive” di pesan kesalahan. Saat kegagalan baca, hanya memastikan apakah jalur sasaran di bawah %OneDrive% dan memasukkannya ke pesan sangat mengurangi waktu triase untuk lapangan dan meja bantuan. Jika Anda mendeteksi kesalahan keluarga cloud-file seperti 0x8007016A, yang ideal adalah memberi tahu pengguna “harap periksa keadaan OneDrive”.
• Jangan taruh folder data aplikasi di bawah OneDrive. Di lingkungan KFM, “Dokumen” juga di bawah OneDrive. Taruh pengaturan, basis data, dan file kerja aplikasi di %ProgramData% atau %LocalAppData%, dan jangan pilih Desktop atau Dokumen sebagai lokasi simpan default atau folder impor default. Cara memutuskan apa ditaruh di mana diringkas di “How to Choose Where a Windows App Stores Local Data”.
• Putuskan perilaku ketika pengguna memilih lokasi di bawah OneDrive. Untuk aplikasi yang membiarkan pengguna memilih lokasi simpan, sertakan di spesifikasi lebih dulu keputusan rancangan seperti memperingatkan ketika jalur yang dipilih di bawah OneDrive (di bawah jalur variabel lingkungan OneDrive / OneDriveCommercial), atau menolak hanya penempatan file kunci atau DB.

7. Respons sisi IT — kendalikan dengan pin dan kebijakan

Dari posisi IT, operasi yang realistis bukan “matikan File Sesuai Permintaan seluruhnya” melainkan menjamin isi nyata hanya di tempat bisnis membutuhkannya.

• Sematkan folder yang dibaca aplikasi bisnis. Pilih “Selalu simpan di perangkat ini” dari menu klik kanan Explorer, atau jalankan attrib +p -u <folder> /s /d dari skrip pencitraan (Anda menentukan -u pada saat yang sama agar campuran file yang sudah hanya-daring dialihkan andal ke disematkan). File yang disematkan punya isi nyata dijamin secara lokal dan juga di luar konversi otomatis ke hanya-daring yang dibahas kemudian.⁷²
• Konfigurasikan KFM dan File Sesuai Permintaan “dengan sengaja”, bukan “ternyata menyala ketika kami sadar”. Kebijakan utama (Kebijakan Grup / Intune) sebagai berikut.¹¹¹

• Ketahui bagaimana Storage Sense bergerak. Storage Sense punya fitur yang otomatis mengembalikan file cloud yang tidak dibuka selama sejumlah hari ke hanya-daring, dan Anda dapat mengonfigurasi jumlah hari dengan kebijakan (ConfigStorageSenseCloudContentDehydrationThreshold). Default adalah 0 (jangan kembalikan otomatis), tetapi jika pengguna telah menyalakannya dari layar pengaturan, atau organisasi mengonfigurasinya untuk perangkat berkapasitas rendah, “file yang dibuka minggu lalu kembali ke ikon awan” terjadi sebagai perilaku normal. File yang disematkan di luar cakupan, jadi “sematkan folder bisnis” bekerja di sini juga.¹²²

flowchart TB
    accTitle: Cabang konversi otomatis ke hanya-daring oleh Storage Sense
    accDescr: Dalam pembebasan otomatis Storage Sense, file yang disematkan di luar cakupan dan isi nyata dipertahankan; file yang tidak disematkan yang tidak dibuka selama sejumlah hari dikembalikan ke hanya-daring
    ss["Pembebasan otomatis Storage Sense"] --> pin{"Disematkan?"}
    pin -->|Ya| stay["Di luar cakupan; isi nyata dipertahankan"]
    pin -->|Tidak| old{"Tidak dibuka selama sejumlah hari?"}
    old -->|Ya| dehyd["Dikembalikan ke hanya-daring"]
    old -->|Tidak| keep["Isi nyata dipertahankan"]
    ss -.-> def["Default 0 tidak mengembalikan otomatis"]

Gambar 17: Storage Sense mengembalikan file yang tidak dibuka selama sejumlah hari ke hanya-daring, tetapi pin di luar cakupan.

• Perkirakan dampak sebelum menonaktifkan File Sesuai Permintaan. Menonaktifkan FilesOnDemandEnabled menjadi sinkronisasi unduhan penuh klasik, tetapi konsumsi disk dan beban bandwidth sinkronisasi pertama melonjak. Microsoft merekomendasikan membiarkannya menyala, dan Anda harus memperlakukan penonaktifan sebagai tindakan terbatas setelah memastikan bahwa “volume data pengguna sasaran kecil” dan “ada ruang disk”.¹¹²
• Bangun ke dalam prosedur dukungan. Memasukkan prosedur triase bab berikutnya ke templat pertanyaan “file di desktop tidak mau terbuka” menjaga mutu respons bahkan ketika orang yang menangani berganti.

8. Prosedur triase — ketika Anda ditanya “file tidak mau terbuka”

Ketika Anda menerima konsultasi, pastikan dari atas ke bawah.

Tindakan darurat adalah mengklik kanan folder sasaran dan memilih “Selalu simpan di perangkat ini” (atau attrib +p /s /d). Itu merapikan isi nyata secara lokal dan bisnis dapat dilanjutkan. Di atas itu, putuskan apakah penyebab esensial ada di sisi aplikasi (Bab 6) atau sisi IT (Bab 7) sebagai respons permanen.

flowchart TB
    accTitle: Jalur dari tindakan darurat ke respons permanen
    accDescr: Sebagai tindakan darurat, menetapkan folder sasaran ke Selalu simpan di perangkat ini merapikan isi nyata secara lokal agar bisnis dapat dilanjutkan; di atas itu Anda memutuskan apakah penyebab esensial di sisi aplikasi atau sisi IT dan maju ke respons permanen
    aid["Sematkan sebagai darurat"] --> restore["Isi nyata dirapikan secara lokal"]
    restore --> resume["Bisnis dilanjutkan"]
    resume --> judge{"Di mana penyebab esensial?"}
    judge -->|Sisi aplikasi| dev["Ke respons Bab 6"]
    judge -->|Sisi IT| ops["Ke respons Bab 7"]

Gambar 18: Tindakan darurat adalah menyematkan, merapikan isi nyata, dan melanjutkan bisnis; respons permanen berlanjut setelah memutuskan apakah sisi aplikasi atau sisi IT.

Jika Anda telah memastikan sejauh ini dan “jalur tidak di bawah OneDrive” serta “bukan placeholder juga”, Anda maju ke penyebab langganan lain seperti folder bersama atau panjang jalur. “Pitfalls of Network Drives and UNC Paths” dan “MAX_PATH and Windows Path/Filename Pitfalls” adalah peta untuk selanjutnya.

9. Ringkasan

• KFM mungkin telah memindahkan Desktop, Dokumen, dan Gambar yang nyata ke bawah C:\Users\<nama>\OneDrive\. Aplikasi yang mengasumsikan jalur tetap patah di sini. Merresolusi dengan API folder dikenal adalah langkah pertama.
• File Sesuai Permintaan menyala secara default, dan placeholder tanpa isi lokal ada sebagai hal yang wajar. Placeholder adalah titik reparse Cloud Files API (cldflt.sys), dan membukanya menghidrasi secara otomatis.
• Keadaan dapat dinilai dari atribut file (OFFLINE / RECALL_ON_DATA_ACCESS / PINNED / UNPINNED) dan muncul sebagai O, P, dan U di attrib. Memeriksa atribut saja tidak menyebabkan unduhan.
• Kecelakaan aplikasi bisnis muncul sebagai kegagalan hidrasi saat luring, unduhan penuh dari proses batch, kode yang tidak mengharapkan 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 buka semena-mena”, “jangan taruh folder data di bawah OneDrive”, dan “katakan bahwa itu di bawah OneDrive ketika Anda error”.
• Di sisi IT, Anda menciptakan keadaan yang dimaksud dengan “menyematkan folder bisnis” dan “kendali kebijakan KFM, File Sesuai Permintaan, dan Storage Sense”.
• Triase dapat dilalui secara mekanis dalam urutan jalur → attrib → OneDrive berjalan → jaringan → ruang bebas → catatan.

Lain kali Anda ditanya “filenya ada tetapi tidak mau terbuka”, tanyakan ini dulu.

Apakah file itu benar-benar di disk lokal? Atau hanya tampilan cloud yang duduk di sana?

Artikel terkait

• The Depths of Windows I/O (Part 5) — NTFS Internals: Understanding the File System Through the MFT
• A Practical Guide to FileSystemWatcher - Handling Missed and Duplicate Events
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• Mutual Exclusion Fundamentals for File-Based Integration - Best Practices for File Locks and Atomic Claims
• How to Choose Where a Windows App Stores Local Data — A Decision Table for SQLite / JSON / Registry / Access
• MAX_PATH and Windows Path/Filename Pitfalls — the 260-Character Limit, Reserved Names, Trailing Dots, and Case Sensitivity

Area konsultasi terkait

KomuraSoft LLC menangani investigasi kegagalan aplikasi bisnis yang melibatkan OneDrive dan penyimpanan cloud — “impor yang dulu berjalan tidak lagi berjalan setelah penggantian PC”, “file tidak mau terbuka hanya di PC tertentu” — perancangan dan perbaikan pemrosesan file serta pemantauan yang mengasumsikan placeholder, dan tinjauan rancangan lokasi simpan di lingkungan KFM / File Sesuai Permintaan. Memulai dari mengisolasi gejala tidak apa-apa — silakan menghubungi kami.

• Pengembangan aplikasi Windows
• Investigasi bug dan akar masalah
• Konsultasi teknis dan tinjauan desain
• Hubungi kami

Tautan referensi

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 berkata "file tidak ditemukan" dan tidak bisa membaca CSV yang saya taruh di desktop. Mengapa?

Dalam banyak kasus folder desktop sendiri telah dipindahkan ke C:\Users\<nama pengguna>\OneDrive\Desktop oleh Known Folder Move (KFM) OneDrive, atau file telah menjadi placeholder hanya-daring. Aplikasi yang mengasumsikan jalur tetap seperti C:\Users\<nama pengguna>\Desktop tidak menemukan file setelah pemindahan. Bahkan ketika jalur benar, file hanya-daring dapat gagal dibuka saat OneDrive berhenti atau jaringan tidak sehat. Pertama pastikan apakah jalur sasaran berada di bawah OneDrive, dan periksa dengan perintah attrib apakah U (hanya-daring) terpasang. Sebagai tindakan darurat, Anda dapat mengamankan isi nyata secara lokal dengan "Selalu simpan di perangkat ini" pada menu klik kanan.

Bisakah program mengetahui apakah file hanya-daring?

Ya. Placeholder hanya-daring membawa atribut seperti FILE_ATTRIBUTE_OFFLINE dan FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (0x00400000), jadi Anda dapat menilai keadaan dari atribut file tanpa mengunduh isi. Mengambil atribut atau mengenumerasi folder tidak menyebabkan hidrasi (unduh). Di .NET beberapa nilai tidak didefinisikan pada FileAttributes, jadi Anda melakukan cast ke bilangan bulat dan menguji dengan operasi bitwise. Jika Anda benar-benar perlu membuka tanpa membaca isi, sarana seperti FILE_FLAG_OPEN_NO_RECALL pada CreateFile juga tersedia.

Apakah mematikan File Sesuai Permintaan menyelesaikan masalah?

Perlakukan mematikannya sebagai pilihan terakhir. Menonaktifkannya mengunduh setiap file dalam lingkup sinkronisasi secara lokal, sehingga kapasitas disk dan beban jaringan sinkronisasi pertama menjadi besar, dan Microsoft juga merekomendasikan membiarkannya menyala. Dalam praktik lebih fleksibel menetapkan hanya folder yang dibaca aplikasi bisnis ke "Selalu simpan di perangkat ini" (menyematkannya). Secara lebih mendasar, perbaikan andal adalah merancang ulang agar folder data dan folder impor aplikasi tidak berada di bawah pengelolaan OneDrive.

Saya menetapkan "Selalu simpan di perangkat ini", tetapi beberapa file akhirnya kembali ke ikon awan. Mengapa?

Pertama pastikan dengan perintah attrib bahwa file benar-benar memiliki pin (atribut P). File yang disematkan berada di luar konversi otomatis ke hanya-daring oleh Storage Sense, tetapi file yang hanya "tersedia secara lokal" karena seseorang membukanya, tanpa penyematan, dapat dikembalikan ke hanya-daring setelah suatu jangka waktu tergantung pengaturan dan kebijakan Storage Sense. Tindakan "Kosongkan ruang" milik pengguna sendiri, dan kebijakan yang membuat file situs tim hanya-daring (DehydrateSyncedTeamSites), juga mengembalikan ikon awan. Untuk folder yang harus tetap lokal bagi bisnis, operasikan dengan menyematkan pada lingkup 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.