Riprendere un trasferimento SFTP interrotto

Riprendi un download solo se il file locale parziale è l’inizio invariato del file remoto attuale. Riavvia un caricamento interrotto dal byte zero. Il server SFTP di dosya supporta letture con offset, ma il suo handle di scrittura parte con un buffer vuoto a ogni OPEN; l’opzione Resume del client non può ricostruire in sicurezza il prefisso esistente di un caricamento.

La distinzione conta anche se il client offre sia Resume sia Overwrite. Una capacità generica del client SFTP non dimostra che sia supportata dal server di archiviazione connesso.

Decidere se riprendere

Direzione interrotta	Recupero sicuro
Download da dosya al computer	Usa un client con offset, come OpenSSH reget, solo se il file remoto e il prefisso locale non sono cambiati.
Caricamento dal computer a dosya	Disattiva Resume/Append e invia di nuovo l’originale intero, preferibilmente con un nome univoco di prova o recupero.
Direzione o identità del file parziale incerta	Conserva una copia del file locale parziale, poi avvia un nuovo trasferimento verso un percorso diverso.

Per un download ripreso, il client normalmente inizia a leggere dalla lunghezza del file locale parziale. Il server accetta richieste READ con un offset in byte e restituisce EOF quando l’offset raggiunge la dimensione remota. Non confronta i byte parziali con il prefisso remoto e non negozia un’istantanea bloccata tra sessioni disconnesse. Nomi o dimensioni uguali da soli non provano che il contenuto sia invariato.

Passaggi: riprendere un download invariato con OpenSSH

1. Conserva il file interrotto nel percorso locale esistente. Verifica spazio di lavoro, cartella remota e nome che lo hanno prodotto. Non rinominare un altro file facendolo passare per quel parziale.
2. Riconnettiti con email e chiave API e con la chiave host SSH attendibile:

sftp -P 2222 -o User=you@example.com -o PreferredAuthentications=password -o PubkeyAuthentication=no sftp.dosya.dev

3. Al prompt entra nello stesso spazio di lavoro e nella stessa cartella remota. Confronta le informazioni ls -l con il trasferimento originale: una sorgente più piccola, una versione cambiata o un file diverso richiedono un nuovo download completo. Se un altro membro o un’integrazione potrebbe averlo sostituito, usa get verso un nuovo percorso locale.
4. Se l’origine è invariata e il file parziale è quello autentico, esegui:

sftp> cd "My Workspace"
sftp> reget source.bin ./source.partial.bin

Sostituisci entrambi i nomi con i percorsi reali. Il manuale sftp di OpenSSH documenta reget come ripresa del download e avverte che contenuti esistenti cambiati possono corrompere il risultato. Controlla nel manuale del client installato che il comando sia supportato. Non sostituirlo con reput, che riprende un caricamento. 5. Al completamento confronta numero finale di byte e SHA-256 completo con un originale attendibile o un riferimento scaricato separatamente. Un download ripreso può raggiungere la dimensione prevista pur contenendo un prefisso diverso.

Su macOS esegui shasum -a 256 source.partial.bin source.reference.bin per stampare entrambi gli hash, poi confronta tu i due valori esadecimali; il comando non verifica automaticamente l’uguaglianza. In Windows PowerShell usa Get-FileHash -Algorithm SHA256 per ogni copia locale e confronta gli hash riportati. Valori SHA-256 uguali confermano che tutti i byte corrispondono; confrontare i nomi non basta.

Risultato previsto

Un download ripreso ha il numero completo di byte e lo SHA-256 dell’originale. Un caricamento riavviato compare come file cloud completo dopo la chiusura finale riuscita, senza dipendere da un precedente file parziale sul server.

Test innocuo della ripresa del download

Usa un file remoto sacrificabile di cui possiedi già i byte originali in locale, con nome nuovo e senza modifiche contemporanee. Evita file sensibili o insostituibili. Scaricalo in resume-check.partial.bin, interrompi il client dopo l’arrivo di alcuni byte e lascia il file locale parziale dov’è. Riconnettiti alla stessa origine e usa reget sullo stesso percorso del file parziale.

Confronta dimensione remota o dell’origine, dimensione locale finale e SHA-256 con l’originale. Se il client ha rimosso il file parziale o ha completato il trasferimento prima dell’interruzione, non c’è nulla da riprendere; ripeti solo con un file innocuo sufficientemente grande. Il test verifica il percorso di download del client senza affermare che la ripresa dei caricamenti in produzione funzioni. Durante la stesura non è stato eseguito un test live del protocollo.

Recuperare un caricamento interrotto

Il gateway raccoglie le parti di scrittura per connessione e avvia il completamento del caricamento dosya al CLOSE. Non espone le parti nel buffer come file remoto parziale persistente prima di quel completamento. Perdere la connessione prima di CLOSE non lascia quindi un prefisso salvato da riprendere. Se la connessione cade durante o dopo CLOSE, l’operazione nel backend potrebbe già essere completata; controlla File, dimensione e byte scaricati prima di decidere che il caricamento sia fallito.

Ogni nuovo OPEN di scrittura parte da parti vuote, anche se il nome del file esiste già. In questa implementazione le opzioni append, truncate e creazione esclusiva non garantiscono la conservazione dei byte precedenti né la protezione dalle collisioni. Nei caricamenti piccoli, gli intervalli non inviati possono diventare byte zero durante l’assemblaggio; l’assemblaggio multipart più grande rifiuta gli intervalli non contigui. Un caricamento ripreso solo dall’offset può quindi fallire o sostituire un file esistente con contenuto corrotto. Evita Resume, Append, reput, put -a e la ripresa automatica dei caricamenti del client.

Per recuperare, conserva l’originale locale completo. Scegli un nuovo nome di destinazione, riconnettiti e usa un normale put che invii l’intero file dall’offset zero. Attendi il risultato della chiusura, poi scarica la copia cloud completa in un altro percorso locale e confronta tutti i byte o l’hash. Solo dopo la verifica organizza o sostituisci intenzionalmente la destinazione esistente.

Se lo stesso nome esiste già nel cloud, un caricamento completo normale usa il percorso di sostituzione o versione dosya. Le versioni precedenti hanno conservazione limitata: il numero predefinito è 10 e le versioni più vecchie dei proprietari gratuiti sono soggette a pulizia dopo sette giorni. Una sovrascrittura non garantisce una copia di sicurezza indefinita. Le operazioni rm/rmdir del client eliminano il contenuto cloud nel cestino, se consentito, e revocano i link di condivisione associati; non rimuovere un originale remoto valido per facilitare la ripresa. L’eliminazione definitiva perde irreversibilmente il contenuto salvato.

Limiti, tempi ed errori

Il gateway SFTP distribuito consente caricamenti fino a 352 MiB, ma disponibilità dello spazio, regole di dimensione o tipo di file dello spazio di lavoro e limiti espliciti della chiave o del ruolo possono essere più restrittivi. Caricare solo la parte finale non evita il limite: l’offset più alto scritto partecipa al controllo della dimensione. I normali download usano letture con offset e, da 64 MiB in su, richieste a intervalli limitati anziché una lettura dell’intero file. La ripresa può ridurre i byte ritrasmessi al client locale, ma ogni autorizzazione di download nuova o rinnovata è conteggiata per la dimensione completa del file di origine. Riaprire un download richiede una nuova autorizzazione; anche aggiornare un URL di download a intervalli scaduto può richiederne un’altra. La ripresa non garantisce quindi che la quota di traffico in uscita sia addebitata solo per la parte rimanente.

Una pausa alla chiusura finale è prevista perché il trasferimento verso l’archiviazione cloud inizia in quel momento; non è un file parziale SFTP persistente in attesa di Resume. Attendi il successo o l’errore esplicito e poi controlla la destinazione. Non è garantita una durata di completamento.

Errore o risultato sospetto	Azione successiva
no such file / no such file or directory	Ricontrolla spazio di lavoro e percorso remoti; verifica se l’origine è stata spostata o rimossa.
handle is not open for reading o unknown or already-closed file handle	Riconnettiti con un nuovo handle di download; uno disconnesso non può essere riutilizzato.
write past the … MB per-file limit	Invia il file completo con un altro strumento di caricamento adatto; riprovare con offset non aumenta il limite.
upload finished with … bytes of non-contiguous data still parked	Riavvia il caricamento dall’offset zero; il client ha lasciato un intervallo mancante.
close failed: API …	Controlla lo stato API, i dettagli del criterio e File. Una percentuale di avanzamento non conferma il completamento.
Dimensione corretta ma hash diverso	Conserva la copia sospetta, poi scarica nuovamente tutto da una fonte confermata in un nuovo percorso.

La cache di accesso SFTP o del ruolo corrispondente può conservare un esito su chiave o ruolo fino a 60 secondi. L’autorizzazione API ha cache separate, quindi questo intervallo non garantisce la revoca completa; verifica il limite modificato dopo il completamento dell’invalidazione. I permessi sono ricontrollati alla chiusura di un caricamento; una destinazione revocata può rifiutare il completamento finale anche dopo aver accettato i byte. Correggi accesso o limitazioni prima di riavviare e usa una chiave SFTP dedicata senza ancoraggio di cartella né restrizione sugli IP consentiti.

Guide correlate

• Connessione, attendibilità e credenziali SFTP
• Versioni e recupero dei file