Webes publikálásÁllapot: 2026-10
Inkrementális feltöltés FTP-n
Hogyan küldhet egy FTP-feltöltés csak változott fájlokat, ha az FTP nem ad tartalom-hash-t, és mit kell ehhez a statikusoldal-buildnek tennie.
Kutatási kérdés: Hogyan küldhet egy FTP-feltöltés csak változott fájlokat, ha az FTP nem ad tartalom-hash-t?
Projektigény
Osztott tárhely csak FTP-hozzáféréssel, SSH és rsync nélkül. A build minden futáskor a teljes kimenetet újraírta, így az FTP-kliens minden fájlt újnak látott, és mindig mindent feltöltött.
Módszer és ellenőrzés
- A változásészlelési lehetőségek összevetése: módosítási idő (mtime), fájlméret és tartalom-hash.
- A build ideiglenes mappába ír, majd méret és bájtok szerinti összevetéssel szinkronizál a kimenetbe: csak az eltérő fájl íródik, a forrásból hiányzó törlődik.
- SHA-256 manifest és az előző buildhez viszonyított változáslista (feltöltendő és törlendő fájlok).
- pytest a szinkronra és a manifest-diffre; két változás nélküli build után a második változáslista üres.
Eredmények
- Az FTP-eszközök csak fájlméretből és mtime-ból dönthetnek.
- A méret nem megbízható: egy azonos hosszú verzió-paraméter (?v= és 8 karakter) cseréje nem változtat a HTML méretén.
- Az mtime megbízható, ha a build megőrzi a változatlan fájlokét; ekkor a FileZilla „felülírás, ha újabb” beállítása és az lftp mirror --only-newer helyesen működik.
- A hash-manifest az előző buildhez viszonyít, nem a szerverhez: két feltöltés nélküli build után a második lista hiányos.
- A törléssel járó tükrözés a szerveren lévő, buildben nem szereplő fájlokat is törölné, ezért kizárási lista kell hozzá.
Döntés
Két réteg: mtime-megőrző szinkron, hogy bármely FTP-kliens jól döntsön, és hash-alapú változáslista ellenőrzéshez és kézi feltöltéshez. Feltöltő script egyelőre nincs.
Korlátok és nyitott kérdések
- Saját FTPS-feltöltő script helyi állapotfájllal, vagy CI-alapú feltöltés: nyitott kérdés; a tárhely tűzfala tilthatja a külföldi CI IP-címeket (nem ellenőrzött).
- A változáslista nem ismeri a szerver tényleges állapotát.