Problém s FTP - "hidden file already exists"

[KarelII]

Při problémech s připojením do Internetu (dřív se mi to stávalo s GPRS, v současné době s wifi) se mi častěji než zřídkakdy stává, že mi při kopírování souboru "jmeno.pripona" na server (resp. patrně při nekorektním dokončení kopírování a následném opětovném pokusu) na serveru vznikne soubor

".in.jmeno.pripona." (ve stejném adresáři)

kvůli kterému Salamander už nedokáže požadovaný soubor na server nakopírovat



- musím ho odstranit ručně



a následně se o přenos pokusit znovu (třeba i několikrát, po druhém pokusu už se zpravidla naštvu a soubor bez problémů nakopíruju v řádkovým ftp klientem z Windows). Nestrávil jsem výzkumem hodiny, ale zdá se mi že například při používání řádkového klienta k tomuto problému nedochází ("nikdy").



Setkal se už někdo s tímhle problémem? Je opravdu málo věcí, které mi na Salamanderu systematicky vadí, a tohle je jedna z nich (v případě wifi se s ní při špatném počasí potýkám denně).

[ino]

S timto problemem jsem se u ftp pluginu jeste nesetkal (jsem pripojen "dratama" a nemam potize s kvalitou linky)

Zkusim vsak poradit: pro smazani skryteho souboru z ftp lze vyuzit take salamandra. Skryte soubory lze zobrazit nastavenim ve vlastnostech ftp pluginu - tlacitko Advanced... - Command for listing: LIST -a
Po tomto nastaveni by se snad dal usetrit krok rucniho mazani...

[Datalog]

Setkal se už někdo s tímhle problémem?

Nesetkal a to mám GPRS/UMTS (a dříve jen GPRS).

Stávaly se mi jiné problémy, související s pomalou rychlostí, častým padáním (vybitím/přebitím mobilu), dynamickou IP, hodinovými timeouty na straně serveru, atd., ale vždy bylo stejné chování pro Salamader FTP plugin, FileZilla i windowsácké build-in řádkové FTP .

Takže "jenom" v rychlosti připojení / latenci to nebude.

Dělá to i u ostatních serverů? A jak se chovají ostatní GUI ftp (FileZilla, ...) při připojení na daný server (třeba redisplay obvyklý v GUI (list hned po put) má nevhodný vliv, ...).

[ino]

KarleII, vrta mi hlavou dialogove okno z prvniho screenshotu. Na RC2 mi tam pripada moc malo tlacitek, zkousel jsem navodit podobnou situaci, jakou zde popisujete, coz se mi sice nepodarilo, ale pokazde jsem dostal okno s sesti tlacitky volby, a proto se musim zeptat, jestli pouzivate posledni verzi salamandara RC2?

[KarelII]

Skryte soubory lze zobrazit nastavenim ve vlastnostech ftp pluginu - tlacitko Advanced... - Command for listing: LIST -a

Tohle mi zcela jiste uz kdysi z Altapu poradili, ale nejak mi v Salamanderu prislusne nastaveni vypadlo a zapomnel jsem na nej, diky moc. Problem je nicmene v tom, ze kdyz je spojeni obzvlast spatne (coz se stava), takhle si soubor vylistuju a muzu ho smazat, ale pri dalsim pokusu o nahrani se skryty soubor vytvori znova a tak porad dokola, nez to nevydrzim a nahraju ho tam necim jinym nez Salamanderem (coz nastane po druhem pokusu).

RC2 pouzivam a takhle malo tlacitek v tomhle dialogu opravdu je.

Na jiny server pres FTP plugin nic nenahravam, musel bych si nekde kvuli tomu zridit ucet. Jeste na jeden dalsi server kopiruju soubory pres WinSCP, tam jsem se nikdy s nicim podobnym nesetkal. (Na problematickem serveru (FTP) je nejaky RedHat, na neproblematickem (WinSCP/SSH) OpenBSD.)

Na radkoveho FTP klienta ve Windows je v tomhle smyslu spoleh, stejne jako na radkoveho klienta z toho OpenBSD, nicmene (mlhave) tusim ze jsem se se stejnym problemem v minulosti setkaval pri pouzivani WS_FTP LE (kdyz jeste Salamander FTP plugin nemel).

Zrejme je to nejaka specialita na strane serveru, a vzhledem k tomu ze ten temporary soubor jde vzdycky bez problemu rucne smazat, z meho uzivatelskeho pohledu by bylo perfektni kdyby se v Salamanderovi dalo nastavit, aby v podobnem pripade soubor smazal automaticky a zkusil prenos znova, ve chvili kdy se pta uz ten soubor klidne smazat muze.

Obecne bych rekl ze je Salamander ponekud narocnejsi na odezvy vsech zucastnenych komponent, napriklad minuly vikend se mi (poprve) stalo, ze byl extremne pretizeny server a Salamanderem jsem na nej nejake soubory proste nedostal (vsech 61? opakovanych automatickych pokusu selhalo), pres radkoveho klienta jsem je bezprostredne pote nahral.

[Petr Solin]

Tenhle problem uz jsme resili. Jde o zvlastni nastaveni FTP serveru (proftpd), viz HiddenStor na http://www.proftpd.org/docs/directives/ ... nStor.html.

Je to zajimave nastaveni FTP serveru. Nahodil to i u nas, abych to otestoval. Hledal jsem jestli s tim jeste nekdo zapasi a nasel jsem navrzeny patch FTP serveru (proftpd), ktery povoluje automaticky prepis (jmenuje se to AllowTemporaryOverwrite). Nicmene mam pocit, ze to smetli ze stolu, takze z toho nic nebude. Na jine reseni jsem nenarazil, asi to lidi moc netrapi.

Nas postoj k tomuhle problemu je stale stejny: pokud to bude trapit vetsi skupinu uzivatelu, zkusime to nejak obresit (asi nejake nastaveni v bookmarce, ze mame pri chybe zapisu zkouset mazat soubor s predponou ".in.").

Poznamka: pro zobrazeni skrytych souboru na Unixu je nove v kontextovem menu v panelu (s otevrenym FTP) prikaz List Hidden Files and Directories (Unix). Tento prikaz docasne zapne "LIST -a" misto standardniho "LIST". Pokud to zabere a chodite na server casto, urcite se to vyplati nastavit na stalo v bookmarce (jak uz popisoval ino).

[Petr Solin]

Obecne bych rekl ze je Salamander ponekud narocnejsi na odezvy vsech zucastnenych komponent, napriklad minuly vikend se mi (poprve) stalo, ze byl extremne pretizeny server a Salamanderem jsem na nej nejake soubory proste nedostal (vsech 61? opakovanych automatickych pokusu selhalo), pres radkoveho klienta jsem je bezprostredne pote nahral.

Muzete mi na muj email (petr.solin at altap.cz) poslat FTP log takove operace (menu Plugins / FTP Client > Show Logs, menu Log / Save All As)? Je mozne, ze to nejsou jen chyby spojeni a dalo by se s tim neco provest.

[KarelII]

LIST -a je ok, jenomže jak jsem psal, když je připojení trvale špatné, při následném opakovaném pokusu o upload se .in. soubor vytvoří znovu, zase ho smažu a tak bych to mohl opakovat pořád dokola.

Až/když zase narazím na ten případ s 61 neúspěšnými pokusy, log pošlu. Mezitím jsem zjistil že se s vážnými problémy momentálně potýká celá naše síť a řešení je závislé na poskytovateli infrastruktury, což je nejmenovaná dceřinka Českých drah, takže doufám že problémy budou ještě nějakou dobu přetrvávat a podaří se mi stav reprodukovat.