Osoba podpisana jako ACMM-033 <valhalla@interia.pl> w artykule
<news:lkovc7$84r$1@node2.news.atman.pl> pisze:
Użytkownik "Andrzej P. Wozniak" <uszer@poczta.onet.pl.invalid> napisał
w wiadomości news:536ec66b$0$2144$65785112@news.neostrada.pl...
Osoba podpisana jako ACMM-033 <valhalla@interia.pl> w artykule
<news:lkgp6s$7v0$1@node2.news.atman.pl> pisze:
Mam OE, gdzie jest gigant danych (grubo ponad 100GB).
Czyli grubo za dużo.
Bo ponieważ??
* Bo się nie da tego przeszukać w całości. Im więcej małych wiadomości do
przeszukania, tym szybciej natrafia się na ograniczenia w stylu niemożności
podejrzenia wyszukanej wiadomości czy jakiejkolwiek operacji na niej
(oflagowania, oznaczenia jako ignorowanej itd.)
* Bo jeśli wciąż korzystasz z Windows 9x/2000 czy nieaktualizowanego XP,
to się nie da tego skompaktować w całości bez błędu. OE jest programem
32-bitowym również pod względem używanych wewnętrznie typów danych.
To oznacza, że np. widzi wolne miejsce na dysku tylko w granicach 4 GiB.
Im więcej dużych folderów, tym większe prawdopodobieństwo, że w którymś
momencie reszta z dzielenia wielkości wolnego miejsca przez 2^32 będzie
mniejsza niż wielkość folderu, który akurat trzeba skompaktować. Wyobraź
sobie, że masz wolnego miejsca 200 GiB i 1 MiB, ale OE widzi tylko 1 MiB,
więc krzyczy, że brak miejsca na skompaktowanie folderu o wielkości 2 MiB.
Tę uciążliwość usunęli w OE dla XP SP2, a i to nie od razu, ale dopiero
przy okazji przywiązania programu do dysku lokalnego przez robienie backupu
do kosza. Inne 32-bitowe pozostałości można nadal zobaczyć, np. sprawdzając
łączną wielkość plików i miejsca do zwolnienia, kiedy z opcji OE wybierze
się konserwację i kliknie przycisk „Oczyść teraz”. W starszych wersjach OE
wyglądało to tak: http://www.olszynka.pl/usher/usenet/czytniki/OE4GB.png
Teraz wcale nie jest lepiej, a tytuł okienka „Oczyszczanie lokalnych plików”
nadal jest mylący, bo zliczane są tylko foldery synchronizowane, a nie
foldery lokalne.
* Bo do skompaktowania folderów OE w wersji z backupem do kosza (XP SP2+)
potrzeba przynajmniej tyle wolnego miejsca, ile one zajmują (a w przypadku
kompresji NTFS nawet więcej!).
* Bo obsługa wielu serwerów grup dyskusyjnych oznacza przerośnięty plik
folders.dbx, o czym już pisałem. Inne szczegóły niżej.
Wystarczy?
Gdybym chciał wiedzieć, czy to dużo, to bym o to zapytał.
Gdybym wiedział, że będziesz znowu marudził, to bym się w ogóle nie odzywał.
Ale piszę na grupę, a nie prywatnie, więc może inni skorzystają, choćby
plagiatorzy.
- nazwy folderów lokalnych i odpowiadających im plików;
- nazwy folderów synchronizowanych (IMAP, subskrybowane grupy dyskusyjne)
powiązane z identyfikatorami kont w rejestrze;
- stan folderu (m.in. liczba nieprzeczytanych wiadomości, w tym
monitorowanych);
- listy wszystkich folderów IMAP i wszystkich grup dyskusyjnych dla
wszystkich założonych kont.
W tej tożsamości mam tylko ok. tysiąca wszystkich plików, ok. 200 to ów
"backup", a reszta, to pączki - gdzie zawartość folderu przekroczyła by
bezpieczną objętość, tam jest to porozbijane na mniejsze kawałki.
Pomyślnie skopiowany folder usuwam.
Pominąłeś istotne dane, na które zwróciłem uwagę powyżej:
* Nie napisałeś, czy są to foldery lokalne, czy synchronizowane. Korzystając
ze wskazanej wyżej opcji konserwacji możesz policzyć, ile miejsca zajmują
które foldery.
* Nie napisałeś, ile masz razem kont dla serwerów grup dyskusyjnych. Pełna
lista grup Usenetu ma ponad 100 tys. pozycji, co w pliku OE zajmuje ponad
10 MiB, a z krótkimi opisami o jakąś połowę więcej. Przy równoczesnym
testowaniu kilkanastu serwerów z grupami z całego świata rozmiar pliku
Folders.dbx przekroczy 128 MiB i będzie problem z jego skompaktowaniem.
bo dla dużego pliku
Folders.dbx kompaktowanie całości skończy się znanym komunikatem błędu
„Plik jest w użyciu…” – szczegóły patrz niżej.
Do 1.8GB (chyba nie próbowałem większych) kompaktowanie udawało się -
przejście w offline, restart OE i właściwe kompaktowanie.
Kompaktowanie czego się udawało - folderu z wiadomościami? To nie nowina
i nie problem, jeśli masz więcej niż 1 GiB RAM. Pół roku temu, kiedy pisałem
o timeoutach, podawałeś jednak inne liczby. Zapomniałeś o tym czy może
wyszukiwanie nie działa?
A dlaczego ignorujesz różnicę między folderem z wiadomościami a plikiem
Folders.dbx, skoro tylko o ten ostatni pytasz?
"Backupuję Internet"
…co jest praktycznie niemożliwe w jednej tożsamości OE z co najmniej
dwóch powodów:
- archiwum najbardziej ruchliwych grup ma więcej niż 2 GiB, więc nie
zmieści się w jednym pliku dbx OE;
A cóż za problem porozbijać to na mniejsze kawałki? Tylko przy naprawdę
dużych grupach, to trzeba mozolić się z czasochłonnym kopiowaniem części
folderu do kataqlogu na bok... ale i z tym sobie poradziłem, chyba
pl.misc.samochody ma coś kole 2.500.000 postów - udało mi się wciągnąć
wszystkie. Choć łatwo nie było.
A tu ignorujesz różnice między plikami lokalnymi a synchronizowanymi
oraz problemy z wyszukiwaniem.
- są problemy ze skompaktowaniem pliku Folders.dbx większego niż 128 MiB,
a do takiego rozmiaru plik rośnie, gdy zawiera listy grup dyskusyjnych
z wielu serwerów.
Do 1.5G przeważnie jest raczej lekkie, pomijając czasochłonność, a przez
to upierdliwość tegoż. Stwierdzone empirycznie.
Empirycznie to wciąż ignorujesz różnicę między folderem z wiadomościami a
plikiem Folders.dbx. Folders.dbx blokuje się tak jak napisałem, choć nie mam
pewności, czy wynika to z samego rozmiaru pliku, czy może z łącznej liczby
grup na listach. Stwierdzone kilkakrotnie i potwierdzone przy okazji pisania
poprzedniej wiadomości.
Tam napisałem tylko, co nie pomaga, tu napiszę, co w wolnej chwili zrobiłem
po testowaniu różnych serwerów grup, kiedy się okazało, że plik Folders.dbx
spuchł ponad miarę:
Zrobiłem zrzuty ekranu obejmujące pełną rozwiniętą strukturę drzewka
folderów, po czym zamknąłem OE i usunąłem plik Folders.dbx (a raczej
przeniosłem w inne miejsce). Po ponownym uruchomieniu OE straciłem jeden
dzień na odbudowę drzewka na podstawie zrobionych zrzutów, ponowne pobranie
list grup dyskusyjnych i obejście wszystkich folderów, aby odzyskać resztę
danych powiązanych ze strukturą drzewka. Po tej całej akcji przeszedłem
w tryb offline, ponownie uruchomiłem OE i dokonałem pełnego kompaktowania
folderów, które tym razem przebiegło bez żadnych problemów.
Innego sposobu na przerośnięty Folders.dbx nie znam.
Rozwiązaniem jest podział archiwum na różne tożsamości OE, np. według
roczników czy tematyki grup. Przydaje się też postawienie lokalnego
serwera
Musi być w jednej - i będzie.
Jak coś jest do wszystkiego, to jest do niczego ;-P
Zresztą, skompaktowany FOLDERS.DBX miał coś ok. 280 kB. A moż 680... w
każdym razie, grubo poniżej 1M.
Niemożliwe. Sama lista grup z neostrady (bez krótkich opisów) ma powyżej
4 MiB. 280 KB to może być news-archive.icm.edu.pl plus lista folderów
lokalnych.
news (np. Hamstera) i pobieranie grup tylko z niego, aby nie trzymać
w pliku Folders.dbx zbyt wielu list grup.
Wolałbym nie, zresztą, jestem w stanie to zrobić, tylko, że tak powiem,
muszę to intensywnie nadzorować, czy któryś z plików nadmiernie nie
rośnie. W właśnie zagapiłem się i plik przekroczył w końcu granicę, OE
przestał się uruchamiać...
Ćwiczę teraz przycinanie od końca tego pliku, by spróbować choć część
struktury przywrócić do życia. Po uruchomieniu OE jakby coś
przeindeksowywał, plik rośnie powoli,
Który plik tniesz, a który rośnie?
Przypominam, jak wygląda praca z plikami OE. Dane są zapisywane blokami,
przy zmianach bloki ze starą zawartością są oznaczane jako skasowane, zaś
poprawiona zawartość jest dopisywana na końcu pliku, choćby zmianą było
tylko skasowanie niektórych wcześniejszych wpisów. Stąd plik po skasowaniu
danych zajmuje _więcej_ miejsca, zaś przycinanie końca uszkadza ostatnio
dodawane bądź modyfikowane dane, a nie tylko śmieci, jakie się tam znalazły
z przyłączonych do pliku klastrów na dysku.
aż program komunikuje po kilku minutach, że nie wstanie, tak będzie leżał.
OE ma wbudowane timeouty, o czym znowu przypominam. Dzięki temu nie wisi
w nieskończoność, tylko się poddaje po ok. 4 minutach. Na starszych
komputerach do timeoutu może dojść np. przy otwieraniu folderu z bardzo
dużą liczbą wiadomości, jak control.cancel z news-archive.icm.edu.pl.
W związku z tematyką cross + FUT warning.
Nie krosowałem, ani FUT nie widzę.
Bo nie chce Ci się zobaczyć, co jest u mnie w nagłówku, a tam znowu taki sam
cross+FUT.
--
Andrzej P. Woźniak uszer@pochta.onet.pl (zamień miejscami z<->h w adresie)
|
