Piszę metodę synchronizującą dwa katalogi. Na wejściu mam listingi obu
katalogów, każdy rekord zawiera nazwę (katalogu lub pliku) oraz datę jego
ostatniej modyfikacji (mogę mieć również datę utworzenia). Mam też daty
modyfikacji i utworzenia katalogu nadrzędnego.

Rozważmy sytuację, w której dany plik znajduje się w lewym katalogu, ale
nie ma go w prawym. Mogły zajść dwa przypadki:

* Plik został utworzony w lewym katalogu i należy go skopiować do prawego;
* Plik znajdował się w obu katalogach, ale został usunięty z prawego i
należy go usunąć w lewym.

Jak rozróżnić oba przypadki i wybrać właściwy?

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

Dnia Fri, 05 Aug 2011 09:47:46 +0200, Wojciech "Spook" Sura napisał(a):

> Piszę metodę synchronizującą dwa katalogi. Na wejściu mam listingi obu
> katalogów, każdy rekord zawiera nazwę (katalogu lub pliku) oraz datę jego
> ostatniej modyfikacji (mogę mieć również datę utworzenia). Mam też daty
> modyfikacji i utworzenia katalogu nadrzędnego.
>
> Rozważmy sytuację, w której dany plik znajduje się w lewym katalogu, ale
> nie ma go w prawym. Mogły zajść dwa przypadki:
>
> * Plik został utworzony w lewym katalogu i należy go skopiować do prawego;
> * Plik znajdował się w obu katalogach, ale został usunięty z prawego i
> należy go usunąć w lewym.
>
> Jak rozróżnić oba przypadki i wybrać właściwy?
>
> Pozdrawiam -- Spook.

A czy nie jest tak, ze zeby wiedziec o tym czy z prawego plik zostal
skasowany, to musimy znac stan _poprzedniej_ synchronizacji?

do góry

Dnia 05-08-2011 o 10:05:20 Jacek <a...@o...pl> napisał(a):
> A czy nie jest tak, ze zeby wiedziec o tym czy z prawego plik zostal
> skasowany, to musimy znac stan _poprzedniej_ synchronizacji?

Wydaje mi się, że chyba wystarczy sama data ostatniej synchronizacji.
Wszystko wskazuje na to, że bez tej informacji nie uda się tego problemu
rozwiązać. Dzięki za odpowiedź.

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech "Spook" Sura"
>> A czy nie jest tak, ze zeby wiedziec o tym czy z prawego plik zostal
>> skasowany, to musimy znac stan _poprzedniej_ synchronizacji?
>Wydaje mi się, że chyba wystarczy sama data ostatniej synchronizacji.
>Wszystko wskazuje na to, że bez tej informacji nie uda się tego problemu
>rozwiązać. Dzięki za odpowiedź.

Zakładasz, że metadane zawsze będą odpowiadać sytuacji rzeczywistej.
Co dalece nie zawsze jest prawdą.

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,14137471
| http://epsilon.eu.org/ |
/------------------------\

do góry

Dnia 05-08-2011 o 11:49:22 Mariusz Kruk <M...@e...eu.org>
napisał(a):

> epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech "Spook"
> Sura"
>>> A czy nie jest tak, ze zeby wiedziec o tym czy z prawego plik zostal
>>> skasowany, to musimy znac stan _poprzedniej_ synchronizacji?
>> Wydaje mi się, że chyba wystarczy sama data ostatniej synchronizacji.
>> Wszystko wskazuje na to, że bez tej informacji nie uda się tego problemu
>> rozwiązać. Dzięki za odpowiedź.
>
> Zakładasz, że metadane zawsze będą odpowiadać sytuacji rzeczywistej.
> Co dalece nie zawsze jest prawdą.

Chodzi Ci o poleganie na datach plików zapisanych w indeksie?

Oczywiście w grę zawsze wchodzi porównywanie ich zawartości, jednak
wówczas użytkownik przy każdej zmianie musiałby decydować sam, co zrobić z
taką parą, co na dłuższą metę byłoby niezbyt wygodne (a proces analizy
byłby piekielnie wolny). Jeśli proces synchronizacji ma być
zautomatyzowany (i możliwy na nieprzygotowanych do tego wcześniej
katalogach), to trzeba przyjąć jakieś słabsze lub silniejsze założenia. Ja
zakładam, że do synchronizowanych katalogów nie dobierał się żaden wannabe
hacker i daty utworzenia i modyfikacji odpowiadają faktycznemu stanowi
tych plików.

Jeśli masz lepszy pomysł, to rozwiń go proszę, bo chętnie zaimplementuję
bardziej wiarygodny mechanizm. W przeciwnym wypadku będę musiał pozostać
przy danych zapisanych w systemie plików.

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech "Spook" Sura"
>>>> A czy nie jest tak, ze zeby wiedziec o tym czy z prawego plik zostal
>>>> skasowany, to musimy znac stan _poprzedniej_ synchronizacji?
>>> Wydaje mi się, że chyba wystarczy sama data ostatniej synchronizacji.
>>> Wszystko wskazuje na to, że bez tej informacji nie uda się tego problemu
>>> rozwiązać. Dzięki za odpowiedź.
>> Zakładasz, że metadane zawsze będą odpowiadać sytuacji rzeczywistej.
>> Co dalece nie zawsze jest prawdą.
>Chodzi Ci o poleganie na datach plików zapisanych w indeksie?

Owszem. Sama informacja o datach pliku nie daje ci żadnej wiedzy.

>Oczywiście w grę zawsze wchodzi porównywanie ich zawartości,

Co ma do rzeczy zawartość, jeśli z jednej strony plik masz, a z drugiej
nie?
Jeśli nie masz zapamiętanego stanu wcześniejszego, nie masz podstaw do
podjęcia decyzji która to sytuacja - czy dodano do katalogu A, czy
skasowano z B.

>zakładam, że do synchronizowanych katalogów nie dobierał się żaden wannabe
>hacker i daty utworzenia i modyfikacji odpowiadają faktycznemu stanowi
>tych plików.

To nie musi być żadne hakierstwo. Wystarczy rozpakować archiwum.


--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,14137471
| http://epsilon.eu.org/ |
/------------------------\

do góry

Dnia 05-08-2011 o 15:53:45 Mariusz Kruk <M...@e...eu.org>
napisał(a):
> Co ma do rzeczy zawartość, jeśli z jednej strony plik masz, a z drugiej
> nie?
> Jeśli nie masz zapamiętanego stanu wcześniejszego, nie masz podstaw do
> podjęcia decyzji która to sytuacja - czy dodano do katalogu A, czy
> skasowano z B.

Bawię się właśnie w tle darmowym programikiem Microsoft SyncToy. W każdym
synchronizowanym katalogu (tylko głównym) zapisuje pojedynczy plik o
rozmiarze 16 bajtów, a jednak wystarcza mu to w zupełności do
stwierdzenia, które pliki usunąć, a które skopiować do katalogu docelowego
(nawet po rozpakowaniu plików z archiwum).

Pozdrawiam -- Spook.

--
! ._______. Warning: Lucida Console sig! //) !
! || spk || www.spook.freshsite.pl / _ """*!
! ||_____|| spook at op.pl / ' | ""!
! | ___ | tlen: spoko_ws gg:1290136 /. __/"\ '!
! |_|[]_|_| May the SOURCE be with you! \/) \ !

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech "Spook" Sura"
>> Co ma do rzeczy zawartość, jeśli z jednej strony plik masz, a z drugiej
>> nie?
>> Jeśli nie masz zapamiętanego stanu wcześniejszego, nie masz podstaw do
>> podjęcia decyzji która to sytuacja - czy dodano do katalogu A, czy
>> skasowano z B.
>Bawię się właśnie w tle darmowym programikiem Microsoft SyncToy. W każdym
>synchronizowanym katalogu (tylko głównym) zapisuje pojedynczy plik o
>rozmiarze 16 bajtów, a jednak wystarcza mu to w zupełności do
>stwierdzenia, które pliki usunąć, a które skopiować do katalogu docelowego
>(nawet po rozpakowaniu plików z archiwum).

To przyjrzyj się dokładniej. On używa jednak dużo więcej nż tylko po
jednym pliku per katalog.


--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,14137471
| http://epsilon.eu.org/ |
/------------------------\

do góry

Dnia 08-08-2011 o 18:49:13 Mariusz Kruk <M...@e...eu.org>
napisał(a):
> To przyjrzyj się dokładniej. On używa jednak dużo więcej nż tylko po
> jednym pliku per katalog.

Możesz rozwinąć?

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech "Spook" Sura"
>> To przyjrzyj się dokładniej. On używa jednak dużo więcej nż tylko po
>> jednym pliku per katalog.
>Możesz rozwinąć?

1. Stwórz sobie parę katalogów, zsynchronizuj ją.
2. Wejdź do %localappdata%\microsoft\synctoy\2.0 i usuń te dwa duże
pliki, które tam masz. (zakładam, że nie masz zdefiniowanych innych
par).
3. Z każdego z katalogów z p.1 usuń po jednym pliku. Z każdego inny.
4. Spróbuj zapuścić synchronizację jeszcze raz.

Bez informacji o wcześniejszym stanie, program uzna, że pliki są nowe
i należy je wkopiować do drugiego katalogu, a nie że nastąpiło
usunięcie.

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,14137471
| http://epsilon.eu.org/ |
/------------------------\

do góry