Autor: Wojciech Myszka (myszka_at_ldhpux.immt.pwr.wroc.pl)
Data: Thu 21 Apr 1994 - 07:40:23 MET DST
Kilka dni temu pojawila sie na tej liscie informacja o tym, ze ftp (w
pewnych warunkach) potrafi wznowic przerwana transmisje pliku. Nie wiem,
czy spotkala sie ona z pelna obojetnoscia (Wiadomo, tak wlasnie
jest...) czy tez moze z niedowierzaniem (To jest zupelnie niemozliwe!).
Ja bylem zdziwiony. W zwiazku z tym przeprowadzilem badanie i pragne sie
podzielic swoimi wnioskam z tymi, ktorzy o tej mozliwosci nie wiedzieli.
(Jezeli dla kogos nie jest to nowina - niech przerwie czytanie tego
listu :-)
Jakie warunki musza byc spelnione, aby moc skorzystac z tej mozliwosci?
1. Polaczenie musi byc realizowane z serwerem oferujacym taka mozliwosc.
(Nie wszystkie serwery ja realizuja, szybkie sprawdzenie pozwolilo
stwierdzic, ze porzadne archiwa publiczne na ogol tak.) Aby sie
o tym przekonac nalezy (po uzyskaniu polaczenia z serwerem) wydac
komende "rhelp" "remotehelp" (lub "quote help"); w odpowiedzi powinnismy
otrzymac na ekranie wykaz komend realizowanych przez serwer, komendy
ktore nie sa realizowane zaznaczone sa zazwyczaj gwiazdka (*) - wsrod
komend realizowanych powinna sie znajdowac komenda REST. (Jak zauwazylem
Solaris jej nie oferuje.)
2. Program ftp, z ktorego korzystamy powinien realizowac komende
wznowienia transmisji (radze zapoznac sie z dokumentacja lub w
najgorszym razie wydac polecenie "help"); szukamy komendy "restart", na
niektorych komputerach moze byc zrealizowan komenda "reget" (w ostatnim
przypadku sprawa jest bardzo prosta; w pierwszym bardziej
skomplikowana). Uwaga jak wyzej.
Jaka powinna byc metodologia postepowania (przy zalozeniu, ze oba powyzsze
warunki sa spelnine)?
Po przerwaniu polaczenia, zapisujemy dlugosc juz przetransferowanego pliku
(nazwijmy ja nnn), nawiazujemy polaczenie na nowo, przechodzimy do
odpowiedniej kartoteki (tej, z ktorej sciagalismy plik), ustalamy
odpowiedni tryb transmisji i wydajemy komende
"restart nnn"
a nastepnie
"get nazwa_pliku"
Powinno zadzialc.
Jezeli uzywana przez nas implementacja ftp realizuje komende reget -
sprawa jest znacznie prostsza: nie musimy zapamietywac dlugosci
przetransportowanego juz pliku, po znalezieniu sie we wlasciwej kartotece
wydajemy komende
"reget nazwa_pliku"
ftp samo sprawdzi dlugosc i ,,wyda'' odpowiednie polecenia.
Przegladajac strony manuala znalazlem inne ciekawe komendy (wlasnosci)
programu ftp (na HP-UX, nie wiem jak jest gdzie indziej), przedstawiam w
ogromnym skrocie:
case - powoduje automatyczna zamiane nazw sprowadzanych zbiorow z liter
wielkich na male (pod warunkiem, ze cala nazwa jest wielkimi
literami) przydatne zwlaszcza przy komendzie mget;
hash - pozwala na biezaco sledzic postep transmisji (ftp dodaje # po
kazdym kawalku przetransferowanej informacji;
newer - sprowadza zbior pod warunkiem, ze jest on nowszy niz posiadany
przez nas;
nmap - pozwala na automatyczna zamiane nazw (i tak komenda
"nmap $1.$2;$3 $1.$2"
pozwala na automatyczne odrzucenie srednika wystepujacego w
nazwach plikow (moje archiwum - na ldhpux tak wlasnie
przedstawia pliki znajdujace sie na CD-ROMie); aby miec pelnie
szczescia mozna jeszce uzyc komendy case;
prompt - pozwala wylaczyc pytanie czy chcemy przetransferowac plik;
runique - pozwala uruchomic takie zachowanie klienta, ze bedzie
przemianowywal sprowadzane zbiory (nie niszczac juz istniejacych
w kartotece);
Tak wiec... czytajmy dokumentacje (RTFM jak mawiaja sieciowcy)
Pozdrowienia
Wojtek
PS Byc moze przy jakiejs okazji (ja lub moze ktos inny zbierze sie) napisze
nieco o zbiorze .netrc, makrach i zastosowaniu tego do ,,automatycznego''
(na przyklad w nocy) transferowania plkow. W
PS PS Nie daje najmniejszej gearancji, ze przedstawione informacje beda
dzialaly na jakimkolwiek komputerze i w sposob zgodny z podanym :-)
-- Wojciech A. Myszka myszka_at_ldhpux.immt.pwr.wroc.pl Technical University of Wroclaw, Institute of Material Science and Technical Mechanics, Smoluchowskiego str. 25 50-370 Wroclaw, Poland, tel. (+48 71) 21-50-28, fax () 21-12-35
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 15:45:09 MET DST