Dropbox nedávno přidal možnost používat soubor rules.dropboxignore, což je něco jako .gitignore pro Dropbox. Za mě super věc. U Python projektů například opravdu nepotřebuji synchronizovat .git, __pycache__, dočasné soubory editorů a podobný balast.
Jenže jsem narazil na poměrně nepříjemný problém. Dropbox se na dvou počítačích tvářil, že je všechno v pořádku, ale obsah adresářů se mezi nimi ve skutečnosti nesynchronizoval.
A nakonec za to mohlo jedno jediné pravidlo:
**/#*Obsah
Jak se problém projevoval
Na pracovním počítači jsem vytvořil nové adresáře a soubory. Dropbox je normálně nahrál do cloudu a na dropbox.com byly vidět.
Na domácí počítač ale nepřišly.
Dropbox přitom:
- hlásil synchronizaci
- nové soubory zobrazoval v Activity
- následně přešel do stavu Up to date
- ale adresáře fyzicky na disku nebyly.
Nešlo přitom jen o online-only režim. Kdyby byl soubor pouze online, měl by být alespoň vidět v Průzkumníku jako placeholder.
Nebyl tam vůbec.
Například:
Test-Path "$env:USERPROFILE\Dropbox\Python\projekty\P088-url-generator"vracelo:
Falsepřestože adresář normálně existoval na dropbox.com a Dropbox desktop klient jeho vytvoření zobrazil ve své aktivitě.
Začal jsem klasickou diagnostikou
První podezření samozřejmě padlo na Selective Sync.
Všechno ale bylo zaškrtnuté.
Pak jsem zkontroloval, jestli Dropbox vůbec sleduje správný adresář:
Get-Content "$env:LOCALAPPDATA\Dropbox\info.json"Výsledek byl správně:
{
"personal": {
"path": "C:\\Users\\username\\Dropbox"
}
}Procesy Dropboxu normálně běžely.
Zkusil jsem tedy vytvořit jednoduchý testovací soubor:
"Dropbox sync test" | Set-Content "$env:USERPROFILE\Dropbox\DROPBOX_HOME_SYNC_TEST.txt"Jenže ani ten se do cloudu nenahrál. Naopak soubor vytvořený na dropbox.com se původně vůbec nestáhl na počítač. Takže chvíli vypadalo, že je rozbitá synchronizace oběma směry.
Dropbox Ignore Rules
V rootu Dropboxu jsem měl rules.dropboxignore.
Používal jsem:
*.jsonl
*.tmp
*.temp
*.bak
*.swp
*.swo
*.blend
*.zip
.~lock.*#
**/.git/
**/.git
**/__pycache__/
**/*.pyc
**/~$*
**/#*Většina pravidel je poměrně jasná.
Například:
**/.git/ignoruje Git metadata uvnitř projektů.
**/__pycache__/Python cache.
A:
**/#*mělo podle očekávání znamenat něco ve smyslu: Ignoruj kdekoliv soubor nebo adresář, jehož název začíná znakem #.
Tedy například dočasné soubory některých editorů. Jenže právě toto pravidlo bylo nakonec problém.
Mezitím jsem stihl rozebrat půl Windows :)
Protože problém vypadal opravdu divně, prošel jsem prakticky celý sync stack.
Dropbox na Windows používá Microsoft Cloud Files API, takže jsem ověřoval CldFlt:
sc.exe query cldfltBěžel normálně.
Stejně tak minifilter:
fltmc filtersukazoval:
dbx
CldFlta oba byly správně připojené na disk C::
fltmc instances -v C:Dropbox měl také správně zaregistrovaný SyncRoot:
C:\Users\username\DropboxZkoušel jsem dokonce Process Monitor od Microsoft Sysinternals. Ten ukázal, že Dropbox se soubory opravdu pracuje a Windows Cloud Files vrstva funguje. Takže to už přestávalo vypadat na problém Windows.
Podezřelá šedá ikonka s mínusem
Pak jsem si všiml něčeho důležitého. U některých úplně obyčejných TXT souborů se zobrazovala šedá ikonka s mínusem. Dropbox tím označuje položky, které jsou ignorované.
To bylo divné, protože třeba:
POST_FIX_TEST.txtneodpovídal žádnému z mých ignore pravidel. Kontrola NTFS Alternate Data Streams navíc neukázala ani explicitní:
com.dropbox.ignoredTakže soubor nebyl ručně označený jako ignorovaný.Začalo být jasné, že problém bude přímo v parseru rules.dropboxignore.
A pak stačilo zakomentovat jeden řádek
Vzhledem k tomu, že poměrně dost času jsem v posledním roce věnoval vytvářením pravidel na HAProxy, což obnášelo i projít řadu školení na TryHackMe, tak mě napadlo jestli se mi nějak nepodařilo „hitnout“ sanitaci právě v ignore files. Prostě snahu obcházení firewall různými crawlery už vidíte automaticky všude :)
Zkusil jsem:
# **/#*Tedy zakomentovat:
**/#*A Dropbox se okamžitě rozjel.
Začaly se objevovat soubory a adresáře, které předtím klient viděl v Activity, ale vůbec je nevytvořil na disku.
Žádný reinstall Windows Cloud Files, žádné ruční zásahy do CldFlt, žádná magie. Stačilo „odstranit“:
**/#*Vypadá to na chybu parseru rules.dropboxignore
Nemám samozřejmě zdrojový kód Dropbox klienta, takže nemůžu říct, co přesně se uvnitř děje.
Chování ale vypadá, jako by parser nějak špatně pracoval se znakem:
#uvnitř patternu.
Teoreticky by se mohlo stát, že si řádek:
**/#*nějak nesprávně rozdělí a začne interpretovat něco mnohem obecnějšího, například samotné:
**/To by vysvětlovalo, proč se jako ignorované začaly chovat i úplně nesouvisející soubory a adresáře.
Pokud vám Dropbox nesynchronizuje nové adresáře
Pokud používáte rules.dropboxignore a Dropbox se chová podobně:
- nové adresáře jsou na dropbox.com
- Dropbox je ukazuje v Activity
- klient tvrdí „Up to date“
- ale na disku nejsou
- případně mají běžné soubory šedou ikonku s mínusem
zkontroloval bych rules.dropboxignore.
A pokud tam máte:
**/#*zkuste ho alespoň dočasně zakomentovat:
# **/#*U mě to problém vyřešilo prakticky okamžitě.
Bug jsem poslal Dropboxu
Pokusil jsem se tenhle problém nahlásit Dropboxu. Bohužel jejich cesta pro report běžného bugu není úplně ideální – Basic účet nemá klasické support tickety a do Community fóra se mi nepodařilo dostat, protože registrační e-mail nedorazil.
Nakonec jsem report poslal podpoře přes Twitter/X.
Každopádně to dávám i sem. Pokud někdo za půl roku bude hledat, proč mu po přidání **/#* do rules.dropboxignore přestal Dropbox správně synchronizovat adresáře, třeba mu tím ušetřím večer diagnostiky Windows Cloud Files API :)