Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Re: WinSCP verzovani

pinepitch wrote:

Predevsim moc dekuji za WinSCP. Vynikajici pocin! Ale k veci: vzhledem k tomu, ze aktualne neexistuje normalne podporovany souborovy system umoznujici verzovani na urovni souboru, a tudiz verzovani je skoro vzdy reseno na aplikacni urovni pomerne drahymi systemy, dovoluji si diletantsky navrhnout upravu WinSCP navazujici na predchozi letite posty zde ve vlakne :)
...
V tomto vlakne drive navrhovany remote recycle bin neni resenim, nebot predpoklada, ze k nemu budou mit pristup vsichni uzivatele, coz velmi casto neni mozne. Smyslem navrhu tedy neni zabranit cilene diverzi, ale umoznit uzivatelskou napravu chyb.

Diky za navrh.
Ale vase reseni take vyzaduje adresar (.Versions), ke kteremu maji pristup vsichni. A na druhou stranu, neni pravda, ze musi mit vsichni uzivatele stejny "Remote recycle bin". (Samozrejme vidim, ze stavajici "Remote recycle bin" neni tak chytry, jako vas navrh/jak potrebujete)
Muj email je v mem profilu.
pinepitch

WinSCP verzovani

Dobry den,
Predevsim moc dekuji za WinSCP. Vynikajici pocin! Ale k veci: vzhledem k tomu, ze aktualne neexistuje normalne podporovany souborovy system umoznujici verzovani na urovni souboru, a tudiz verzovani je skoro vzdy reseno na aplikacni urovni pomerne drahymi systemy, dovoluji si diletantsky navrhnout upravu WinSCP navazujici na predchozi letite posty zde ve vlakne :)

Smyslem navrhu je umoznit spolupracujici skupine lidi sdilet souborove struktury na SFTP serveru (kde maji ruzni uzivatele ruzna prava na ruzne slozky resene pomoci ACL) s minimalizovanym rizikem ztraty dat v dusledku vzajemneho prepsani sdileneho souboru. Je jiste, ze navrh ma k dokonalosti hodne daleko, ale velmi spoleham na to, ze navrh vylepsite a zdokonalite a nejak vhodne zaclenite do WinSCP. Navrh odstranuje nejvetsi bolest takoveho sdileni ve stavajicim provedeni - nemoznost uzivatelskeho dohledani souboru omylem prepsaneho nebo smazaneho jinym uzivatelem. V tomto vlakne drive navrhovany remote recycle bin neni resenim, nebot predpoklada, ze k nemu budou mit pristup vsichni uzivatele, coz velmi casto neni mozne. Smyslem navrhu tedy neni zabranit cilene diverzi, ale umoznit uzivatelskou napravu chyb.

Nekde v nastaveni by pribyly nasledujici volby:
Verzovat: zaskrtavatko
Nazev slozky verzi: .Versions
Hloubka verzovani: N

Pri zapnutem verzovani:
    a) Upload existujici slozky by znamenal slouceni slozek dle stavajicich pravidel, pricemz:
    b) Upload noveho souboru na misto jiz existujiciho nebo jeho smazani se provede takto: Stavajici soubor se presune do slozky .Versions (pokud slozka .Versions neexistuje, vytvori se) ve stejne slozce, kde je soubor. Zaroven se soubor prejmenuje - pred priponu se vlozi vlastnik a datum vcetne casu stavajiciho souboru. Pokud je pocet takovych souboru vetsi nez N, nejstarsi se smazou. Pokud cokoli z uvedeneho selze, ohlasi se chyba, upload souboru se neprovede, stavajici soubor zustane na miste. Pokud by uz soubor se stejnym vlastnikem a casem ve slozce .Versions existoval, pripoji se za cas -1, pripadne -2 atd.

tedy nejak takto:
Podklady.pdf ->Versions/Podklady.jindriskaplacha.2019_05_23_14_53_47.pdf

pripadne:
Podklady.pdf ->Versions/Podklady.jindriskaplacha.2019_05_23_14_53_47-1.pdf


    c) Mazat ve slozkach .Versions lze jen vlastni soubory
    d) Prejmenovani jakychkoli souboru ve slozkach .Versions je zakazane
    e) Upload do slozek .Versions je zakazan
    f) Upload/download zvoleneho stromu slozek prenasi komplet strom vsech podslozek vcetne vsech souboru ale bez podslozek .Versions a souboru v nich


Lze jiste velmi snadno - pouhym vypnutim verzovani ziskat potrebna prava potrebna k nejake nekale akci, ale jak jsem jiz psal, tento rezim predpoklada dobrou vuli a chrani jen pred omyly (nakonec stejne jako bezne souborove sdileni na siti LAN)

Prosim taky o svoleni kontaktovat Vas ohledne dalsich podrobnosti, ktere nechci psat na verejne forum.

Dekuji moc za Vas cas
martin

Re: Rename is better than recycle

This request has been added to tracker.
martin

Re: Rename is better than recycle

Ricoman wrote:

First, remote recycle bin is only available for SFTP, but renaming files would be available for all flavors of FTP.

Neither of these is be possible with SCP. With FTP both is possible, it is just not implemented yet. So this is not an argument.

That does not mean I'm against this. It more people ask for that...
Ricoman

Rename is better than recycle

The renaming scheme that was suggested is much better than the remote recycle bin in some situations.

First, remote recycle bin is only available for SFTP, but renaming files would be available for all flavors of FTP.

Second, keeping the versioned (backup) file in the same directory as the original one allows for easy comparison between all versions. (e.g. easier command to a "diff" program etc)

I feel that simple backup-file renaming is a MUST for any good FTP program, however I have only seen acceptatble implementations of it in AceFTP (which has many other problems of its own.)
martin

Re: Save prior versions during synchronize

poojanwagh wrote:

I take it I can use it with the synchronize feature?

Correct.
poojanwagh

Re: Save prior versions during synchronize

That's exactly what I need. I didn't see that in the docs. (I did look, but apparently not long enough.) Thanks! I take it I can use it with the synchronize feature?
martin

Re: Save prior versions during synchronize

Have you tried remote recycle bin?
poojanwagh

Save prior versions during synchronize

Hi. When I synchronize to a remote server, I'd like WinSCP to save prior versions (backup copies) of files upon re-write or delete.

For example, if I start with the following files:
local (version)           remote (version)

---------------           ----------------
readme.txt (1)            readme.txt (1)


And then modify readme.txt locally:
local (version)           remote (version)

---------------           ----------------
readme.txt (2)            readme.txt (1)


Then I do a sync, I'd like two things to happen: 1) a backup copy of readme.txt is created remotely, either using a specified filename or in a separate directory; and 2) the actual sync from local to remote is performed:

Step 1:
local (version)           remote (version)

---------------           ----------------
readme.txt (2)            readme.txt (1)
                          => readme.txt.1.bak


Step 2:
local (version)           remote (version)

---------------           ----------------
readme.txt (2)            readme.txt (2)
                          readme.txt.1.bak