cwbe coordinatez:
101
63540
63709
6893414
6893464
6893472

ABSOLUT
KYBERIA
permissions
you: r,
system: public
net: yes

neurons

stats|by_visit|by_K
source
tiamat
K|my_K|given_K
last
commanders
polls

total descendants::10
total children::1
show[ 2 | 3] flat
na toto som narazil, ale compact folders je od 3.0 automaticke, takze tam problem nebol. Nasiel som nejake spustenie udrzby, co naozaj netusim co obnasa a zredukovalo sa to na cca 4 GB co je stale nonsens. A je absurdne aby som toto musel absolvovat pravidelne. Takze dakde musi byt chyba zjavne :)




00000101000635400006370906893414068934640689347206893494
w
 w      25.10.2012 - 20:36:15 , level: 1, UP   NEW
to ci je compact folders automaticke od tej verzie by som si netrufal tvrdit.

kazdopadne problem je jednoduchy. volne si to predstav tak, ze mas papier a na nom poznamky, co mas robit. ked prijde nova, napises ju na koniec, ked nejaku vykonas, preciarknes ju. taketo robi aj ten mailbox file. ked don dojde novy mail, napise ho nakoniec. ked nejaky zmaze, "zacmara ho" ale zo suboru fyzicky zmiznut nemusi. rovnako ako to mas s Tvojim poznamkovym papierom.

na papieri sa Ti casom hromadia zacmarane miesta, ale priestor po tych zacmaranych spontanne nepribudne, inak povedane, miesto na papieri je zabrate a nepouzitelne. a take to zostane az kym ... neprepises svoje poznamky na novy papier. tam uz nebudu cmaranice a bude tam len to, co tam byt ma. inak povedane, kym sa s mailboxom nieco neudeje, cely slavny mailboxovy file moze zaberat povedzme 1GB a pritom obsahovat len jeden 1kb mail.

az kym sa nieco neudeje ... a to je to compact folders.

a to autocompact folders tam je, ale treba ho mat aj zapnute. rovnako je tam napisany nejaky threshold, teda hodnota typu "ked uspora dosiahnuta spustenim compact folders dosiahne hodnotu aspon *threshold*, automaticky spusti compact folders".

znie to ako absolutna hovadina, ale nie je to, aj ked navonok to tak neposobi. predstav si, ze mas mailbox o velkosti povedzme 2GB, s ktorym aktivne pracujes a malo by sa "compact folders" robit po kazdom zmazani. ono sa to nezda, ale presuvat 2GB dat nie je uplne casovo nenarocna operacia a takto by si mohol polahky docielit, ze zmazes mail, pockas zodesat sekund, zmazes dalsi, pockas inych zodesat sekund. ano, dalo by sa to ciastocne optimalizovat, ze "ved spravim to az ked vypnem aplikaciu" / ... napadov vela, kazdopadne sposobuje to zdrzanie, preto ten prah. asi tolko.

0000010100063540000637090689341406893464068934720689349406893558
kujon
 kujon      25.10.2012 - 21:35:01 , level: 2, UP   NEW
ze je to automaticky od 3.0 som sa docital a mal som to tak aj nastavene.

princip som pochopil aj z toho co som sa docital, ale takyto objem mailov som nemal za cely zivot (neviem ci si uvedomujes ze by to znamenalo obrat 12 000 mailov s velkostou 1 MB. pricom vacsina je realne max par kB) a uz vobec sa nieco take nemoze vytvorit v priebehu dvoch mesiacov.

a to nemusim asi rozoberat co take by s tym mailom museli robit borci ktorym to narastlo na 160 GB :) proste niekde je nejaky problem, a automaticke compat folders s tym zjavne nic nerobi. rucne spustenie to kus skresava. kazdopadne je to cele dost otravne a rad by som sa tohto problemu zbavil bez kazdodennej udrzby mailoveho klienta...

000001010006354000063709068934140689346406893472068934940689355806893583
w
 w      25.10.2012 - 22:01:47 , level: 3, UP   NEW
je pravda, ze poslednou dobou to ide s TB dole vodou (aj TB aj TB). aky system? ako Ti puchnu foldre? vsetky pausalne?

00000101000635400006370906893414068934640689347206893494068935580689358306893595
kujon
 kujon      25.10.2012 - 22:15:16 , level: 4, UP   NEW
vsetky nie, aj ked je pravda ze disk mi zacina robit haluze. naposledy mi to necakane zaplnilo systemovu particiu tak ze mi to cele zdochlo. teraz sa sprava rovnako, s tym rozdielom ze uz som zistil kde mi takto prudko pribuda dat na disku. a je to v thhunderbirdovom adresari, gmailovy subor INBOX. a zvlada to aj tempom par GB za tyzden. ja mam ubuntu 12.04 ale z toho co som vyguglil je to problem na vsetkych OS.

0000010100063540000637090689341406893464068934720689349406893558068935830689359506893741
w
 w      26.10.2012 - 00:36:55 , level: 5, UP   NEW
popujes ci imapujes? nemas tam tie data cacheovane redundantne ?

000001010006354000063709068934140689346406893472068934940689355806893583068935950689374106893748
kujon
 kujon      26.10.2012 - 00:46:53 , level: 6, UP   NEW
imap. a uz ti nerozumiem :)

00000101000635400006370906893414068934640689347206893494068935580689358306893595068937410689374806893757
w
 w      26.10.2012 - 00:52:08 , level: 7, UP   NEW
raz za uhorsky rok sa mi stavalo, ze ten ci onen mailovy klient mi stiahol tie iste maily este raz, alebo este raz, az ich tam bolo zoparkrat tolko. uplne zbytocne, ale bolo. tzn. ci sa v tych puchnucich priecinkoch nenachadza nejaky mail viac krat

0000010100063540000637090689341406893464068934720689349406893558068935830689359506893741068937480689375706893775
kujon
 kujon      26.10.2012 - 01:22:54 , level: 8, UP   NEW
no ono to zjavne dava dokopy podla serverov, takze gmailove mam v jednom subore zrejme. ale lustrovat 10 GB textovy subor, na to naozaj nemam trpezlivost :) ale po tom ako to skresal na 4 GB pribudol dalsi gmailovy subor, takze neviem ci mi toto nejako pomoze...

000001010006354000063709068934140689346406893472068934940689355806893583068935950689374106893748068937570689377506893868
w
 w      26.10.2012 - 08:44:24 , level: 9, UP   NEW
imho staci grepovat headery mailov a potom zistit, ci su vramci daneho suboru / adresara unique alebo nie

00000101000635400006370906893414068934640689347206893494068935580689358306893595068937410689374806893757068937750689386806909187
kujon
 kujon      06.11.2012 - 12:12:58 , level: 10, UP   NEW
velmi nerozumiem co mam spravit :)

btw, realny objem mailov je 230 MB, v thunderbirde narastlo na 16 GB. To by znamenalo cca 80 duplicitnych kopii ak sa nemylim :) Volaco tu bude seriozne dojebane.