Hur man spårar en fjärrfilöverföring som misslyckas vid samma filstorlek

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How to Trace a Remote File Transfer That Fails at the Same File Size - Zima Store Online

En överföring som upprepade gånger misslyckas vid samma byteantal träffar vanligtvis en deterministisk gräns eller ett steg efter överföringen snarare än slumpmässig paketförlust.

För en fjärr-NAS eller självhostad filservice kan den synliga felpunkten komma från målets filsystem, ledigt utrymme eller kvotbegränsning, en applikationsuppladdningsgräns, en omvänd proxy, en 32-bitars klienträknare, en fast anslutningstid eller kontrollsummehantering efter att nyttolasten anlänt. Den snabbaste diagnosen registrerar exakt byteoffset och förfluten tid, och ändrar sedan filstorlek, överföringshastighet, protokoll och destination en variabel i taget.

Registrera Exakt Byteoffset och Fel Fasad

Kör samma överföring två gånger och registrera källstorlek, överförda bytes, procentandel, förfluten tid, klientfel, serverfel och om en partiell fil finns kvar. Skilj på fel under nyttolastöverföring och fel under namnbyte, kontrollsumma, commit, indexering eller slutlig API-bekräftelse.

En WinSCP-supportärende misslyckades upprepade gånger vid 4 GB tills användaren identifierade en FAT32-filstorleksgräns. Den exakta bytegränsen avslöjade en lagringsbegränsning snarare än ett SFTP- eller SCP-routningsproblem.

Om byteantalet är identiskt inom en liten marginal, prioritera fasta gränser och heltalsgränser. Om förfluten tid är identisk men byteantalet ändras med överföringshastigheten, prioritera anslutnings-, proxy-, inaktiv- eller autentiseringstidsgränser.

Ändra Överföringshastighet för att Separera Storlek från Tid

Överför samma fil en gång via den normala fjärrvägen och en gång via en avsiktligt långsammare eller snabbare väg. Registrera om felet följer samma byteantal eller samma varaktighet.

En Dropbox API-diskussion fann att filer som verkade misslyckas över 4 GB istället kunde spegla en HTTP-förfrågnings-tidsgräns, och föreslog delvis nedladdning baserad på intervall för att undvika en lång förfrågan.

När byteantalet ändras men förfluten tid förblir stabil, undersök tunnelns sessionslivslängd, proxy-läsningstidsgräns, utgående tokens och inaktivitetsdetektering. När felet stannar vid ett exakt bytevärde trots stor hastighetsförändring, fortsätt med filsystem, kvot, klient- och applikationsgränser.

Testa Flera Filer Runt Den Misstänkta Gränsen

Skapa eller välj filer precis under, exakt vid och precis över den felande storleken. Testa också en annan fil med samma storlek så att innehåll, filnamn, komprimering och metadata inte blir dolda variabler.

En FlashFXP-forumrapport beskrev en FTP-överföring som stoppade exakt vid 4,00 GB. Gränser i potenser av två som 2 GB, 4 GB eller 8 GB pekar ofta på en räknare, filsystem eller applikationsgräns.

Om varje fil över tröskeln misslyckas, undersök hårda gränser. Om bara en fil misslyckas, jämför sökvägslängd, filnamnstecken, sparsamma områden, behörigheter, käll-läsfel och om serverbehandling behandlar den filtypen annorlunda.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Kontrollera Målets Filsystem, Kvot och Temporärt Utrymme

Identifiera filsystemet som håller den slutliga filen och filsystemet som håller temporära uppladdningar. Kontrollera maximal filstorlek, lediga bytes, lediga inoder, användarkvot, datasetkvot, container-volymkapacitet och eventuellt staging-partition.

En fjärrtjänst kan acceptera hela strömmen till en temporär plats och bara misslyckas när den flyttar eller committar filen. Det ger ett klientfel nära 100 procent även om nätverksvägen levererade nästan alla bytes.

Överför samma fil till en annan share eller dataset på samma NAS. Om gränsen följer destinationen, åtgärda dess filsystem, kvot eller staging-utrymme; om den följer klienten eller protokollet över destinationer, fortsätt utanför lagringslagret.

Undvik Appen, Proxyn eller Tunneln Ett Lager i Taget

Jämför det normala fjärrarbetsflödet med ett direkt protokolltest: SFTP istället för webbuppladdning, direkt VPN-åtkomst istället för en offentlig omvänd proxy, eller en lokal LAN-överföring istället för den fjärrtunneln. Behåll samma källa och destinationslagring.

En rclone-användare upptäckte att stora uppladdningar upprepade gånger startade om efter en lång paus tills tidsgränsen ändrades, medan servern verkade utföra kontrollsummearbete efter uppladdning. Detta illustrerar varför ett fel i slutet av samma fil inte alltid är en bytegräns.

Om direkt SFTP lyckas medan webbvägen misslyckas, undersök applikations- och proxyuppladdningsgränser. Om lokal överföring lyckas men varje fjärrprotokoll misslyckas vid samma förflutna tid, undersök tunneln, ISP-vägen, sessionslivslängd och mellanliggande enheter.

Verifiera Åtgärden med Återupptagnings- och Kontrollsummeprov

Efter att ha korrigerat den misstänkta gränsen, upprepa filer under och över den gamla gränsen. Testa om protokollet återupptar en avsiktligt avbruten överföring och om den slutliga filens hash matchar källan.

ZimaSpace-arbetsflödet för staging av stora NAS-överföringar erbjuder ett säkrare sätt att testa om utan att starta om ett multi-terabyte-jobb från början.

Diagnosen är komplett först när den gamla gränsen korsas upprepade gånger, servern committar filen, kontrollsumman stämmer och loggar identifierar det korrigerade lagret. Acceptera inte automatiska omförsök som döljer ett deterministiskt fel och tyst slösar bandbredd.