Hm, niestety usunięcie tych wierszy z nagłówków również nic nie dało. W takim razie być może to kwestia wersji programu. Bo zakładam, że w ustawianiu filtru nie mogłem się walnąć, skoro wykrywa niektóre wiadomośći (przekleiłem po prostu jak leci, wpisałem przykładową wartość, a jako warunek dałem, żeby każdą wiadomość badał). W każdym razie opisanym wcześniej ręcznym sposobem udało mi się osiągnąć zamierzony cel i choć zagadka tego filtra trafi do archiwum x, to muszę przyznać, że poznawanie niuansów The Bata było ciekawą sprawą. Jeszcze raz dzięki za pomoc!

OK, wklejam dwa przykładowe smile

From XXXXXXX@speed-server.net  Tue Nov 11 09:25:36 2003
Received: from mailic01.gazeta.pl (unverified [193.42.231.60]) 
    by  (imail1.gazeta.pl) with ESMTP id 13295942 
    for <XXXXXXX@poczta.gazeta.pl>; Mon, 10 Nov 2003 18:28:37 +0300
Return-Path: <XXXXXXX@speed-server.net>
Received: from mail.speed-server.net ([217.97.211.13]) by mailic01.gazeta.pl ; Mon, 10 Nov 2003 18:28:37 +0100
Received: from dom (unknown [192.168.0.250])
    by mail.speed-server.net (Postfix) with ESMTP id CE0AEF68CA
    for <XXXXXXX@gazeta.pl>; Mon, 10 Nov 2003 18:29:17 +0000 (UTC)
From: =?iso-8859-2?Q?Kierownik_Ds._Obs=B3ugi_Klienta?= <XXXXXXX@speed-server.net>
To: XXXXXXX@gazeta.pl
Subject: Informacja
Date: Sun, 10 Nov 2002 18:31:12 +0100
Message-ID: <000f01c288de$f7191a90$fa00a8c0@dom>
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_000_0010_01C288E7.58DD8290"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-DSMTPFooter: true
X-Rcpt-To: <XXXXXXX@poczta.gazeta.pl>
Status: RO
X-UIDL: 1068485318.28614_270344.imail1

------=_NextPart_000_0010_01C288E7.58DD8290
Content-Type: text/plain;
    charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

[treść pierwszej wiadomości]

From XXXXXXX@go2.pl  Fri Aug 16 17:50:17 2002
Return-Path: <XXXXXXX@go2.pl>
Delivered-To: medianet.pl-XXXXXXX@medianet.pl
Received: (qmail 12602 invoked from network); 12 Aug 2002 19:48:58 -0000
Received: from tom.enternet.com.pl (195.117.152.65)
  by virtual.medianet.pl with SMTP; 12 Aug 2002 19:48:58 -0000
Received: by tom.enternet.com.pl ('IDeal SMTP, v.31337+mlask_patch_666')
    id 8C28D95038; Mon, 12 Aug 2002 21:48:57 +0200 (CEST)
Delivered-To: XXXXXXX@enternet.com.pl
Received: from rekin.go2.pl (smtp.o2.pl [212.126.20.27])
    by tom.enternet.com.pl ('IDeal SMTP, v.31337+mlask_patch_666') with SMTP id 7CF2C94CA3
    for <XXXXXXX@thexfiles.prv.pl>; Mon, 12 Aug 2002 21:48:57 +0200 (CEST)
Received: from XXXXXXX(c6-180.icpnet.pl [62.21.6.180])
    by rekin.go2.pl (Mailer_v2.01) with SMTP id C761B6EEED
    for <XXXXXXX@thexfiles.prv.pl>; Mon, 12 Aug 2002 21:48:55 +0200 (CEST)
Message-ID: <000701c0bd40$543e4ea0$b406153e@XXXXXXX>
From: "Tom Boone" <XXXXXXX@go2.pl>
To: XXXXXXX@thexfiles.prv.pl
Subject: The Reporter
Date: Wed, 4 Apr 2001 21:49:13 +0200
MIME-Version: 1.0
Status: RO
X-UIDL: 1029181738.12605.virtual.medianet.pl
Content-Type: text/plain;
    charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600

[treść drugiej wiadomości]

A już chciałem robić zrzut ekranu na dowód, że nie mogę znaleźć opcji podgląd wink
W każdym razie przetestowałem tą drugą metodą i oto co się stało. W przypadku wiadomości z nietypowym formatem "Date" w nagłówku rzeczywiście wyświetla się absurdalna data (1 z pośród 5 złych wiadomości na których robię test). W pozostałych przypadkach data wyświetlana jest w porządku, ale to też dlatego, że tam "Date" jest w normalnym formacie. Tak więc okazuje się, że to jednak nie kwestia tego jak zapisana jest data jest problemem, gdyż pozostałe 4 wiadomości mają tak samo zapisaną datę jak tamte 10, które odczytywane są dobrze. Zastanawiam się gdzie jeszcze można szukać elementów wspólnych i różnic pomiędzy dwoma wiadomościami, aby ustalić dlaczego jedne poddawane są filtracji a inne nie.

Jestem teraz na Viście, a Bat jest 3.0.2.10 (oryginalny, z płytki dołączanej do czasopisma).

Spróbowałem zapuścić ten filtr na pojedynczej wiadomości i rzeczywiście nie zadziałał. Z kolei na innej zadziałał. Z tych 15 testowych wiadomości znowu zadziałał na tych samych 10 co wtedy, a pozostałe 5 pominął. Może jest wrażliwy na coś, co jest w nagłówku jednej z wiadomości, a czego nie ma w innej?

O, znalazłem coś ciekawego, taką różnicę pomiędzy wiadomością identyfikowaną poprawnie, a taką, która jest niewykrywana. Otóż ta wychwytywana prawidłowo ma w nagłówku:

Date: Fri, 13 Apr 2001 02:20:45 +0200

Z kolei ta, która nie jest wykrywana ma nagłówek postaci

Date: Mon Feb 03 18:52:33 CET 2003

Ponadto zrobiłem tak, że wyeksportowałem obie wiadomości na dysk i zaimportowałem je ponownie. Ta nieuszkodzona wyglądała identycznie jak przedtem, a w tej uszkodzonej data zmieniła się na zupełnie inną, choć nic nie zmieniałem w nagłówku. Podejrzewam, że wina leżałą w źle zapisanych nagłówkach. Zamieniłem więc pole date w złej wiadomości tym z dobrej i po zaimportowaniu nie wyświetlała się żadna dziwna data, tylko ta, którą wszczepiłem. Nadal jednak wiadomość nie chciała poddać się filtrowaniu, ale przynajmniej dawała się dobrze eksportować i importować bez utraty informacji o dacie.

Zadanie, które chciałem wykonać za pomocą filtrów już praktycznie ukończyłem ręcznie, sortując wiadomości według received a następnie przewijając je bardzo szybko i patrząc czy w dacie created nagle nie pojawia sie jakiś dziwny rok (tak wiadomości przenosiłem do odrębnego folderu i teraz je wyeksportuje i pozmieniam im daty w formacie unixowym), ale nadal intryguje mnie kwestia tego filtra, bo czuję, że byliśmy naprawdę blisko i magiczne pozostają dla mnie powody nie działania tego.

O, to wygląda idealnie!
Tylko znowu mam pewien problem z wykorzystaniem choćby pierwszego filtra. Gdy wklejam pierwszy zaproponowany przez Ciebie szablon i ustawiam w nim wartość 20, to nadal wynajdywanych jest 10 z 15 wiadomości. Roszerzenie doinstalwoalem wgrywajac pliki do katalogu bata i dodając wtyczkę przez odpowiednie okno w programie, więc to chyba zrobiłem dobrze. Zastanawiam się cóż takiego mogłem zrobić nie tak.

OK, chyba już wiem w czym problem. Przyjrzałem się temu filtrowi i policzyłem sobie coś ręcznie dla przykładowego maila. Załóżmy, że chcę znaleźć różnice większe niż 20 dni.  Czy to nie jest tak, że ten filtr odejmuje od siebie po prostu dwie duże liczby, które zbudował na podstawie dat?

Jeśli dobrze rozumiem, filtr najpierw pobiera datę received, która w moim przypadku wynosi powiedzmy 20050202. Następnie odejmuje od niej datę utworzenia, powiedzmy 20050102 i wychodzi mu wartość 100 (choć w rzeczywistości odstęp pomiędzy tymi dniami to 30 dni).

W końcu podnosi tę wartość do kwadratu i otrzymuje 10000 i sprawdza, czy jest większa od kwadratu dni, czyli w moim przypadku 20*20=40.

Klasyfikuję tę wiadomość jako taką, w której data jest zła i słusznie.

Ale weźmy inny przykład, na przykład wiadomość odebrana dnia 20050102 a utworzona 20041231. Wtedy mamy 20050102-20041231=8`871. Po podniesieniu do kwadratu otrzymujemy wartość 177`844`413`611, która też jest większa od 400, choć rzeczywista różnica pomiędzy wiadomościami to zaledwie 3 dni.

Czy nie jest to jakiś trop w kierunku tego, skąd biorą się błędy? Może chodzi o to, że odejmując YYYYMMDD od YYYYMMDD nie bierzemy pod uwagę tego, że miesiąca ma w przybliżeniu 30 dni a miesięcy w roku jest 12, tylko odejmujemy od siebie dwie duże liczby nie biorąc pod uwagę tego, że np. liczba 20109999 nie może tutaj istnieć?

Mam nadzieję, że nie zakręciłem za bardzo. smile




Może więc w jakiś sposób zmusić  Bata, żeby przekodował te daty w następujący sposób:
data2= DD + 30 * MM + 365 * YYYY
i dopiero je od siebie odejmował?

Wtedy oczywiście założylibyśmy, że każdy miesiąc ma z grubsza 30 dni, ale takie uproszczenie niewiele zmienia. Możnaby nawet od każdego YYYY odjąć liczbę 2000, żeby operować mniejszymi liczbami, bo i tak wszystkie wiadomości mają daty od roku 2000 do 2005. Wtedy ten podany wyżej przykład, który wcześniej nie zadziałał, miały szansę zadziałać, bo:
data2_received= 02 + 30*01 + 5*365=1`857
oraz
data2_created=31 +12*30 + 4*365=1`851

A następnie data2_received - data2created=6
co podniesione do kwadratu daje 36, czyli liczbę mniejszą od 400, a więc zgodnie z oczekiwaniami wiadomosc nie byla by zaklasyfikowana do problemowych.

Pytanie tylko czy to moje rozumowanie ma sens i jak przekodować je na język the Bata. Z informatyką ani programowaniem nie mam nic wspólnego. hmm

Dzięki za przystępne wyjaśnienie. Odpaliłem filtr, ustawiłem mu wartość na 20 dni (czyli wpisałem wartość 400) i zadziałał. Dla pewności zrobiłem sobie w Bacie folder w którym umieściłem 15 wiadomości z których wszystkie powinny zostać wykryte, ponieważ miały różne daty. Z jakiegoś powodu filtr wyłowił tylko 10 z nich. Teraz patrzę na nie i próbuję wyłapać, co ma ze sobą wspólnego skutecznie przefiltrowana 10 i nieskutecznie przefiltrowana 5. We wszystkich 15 pzrypadkach oczywiście różnica jest większa niż 20 dni.

Dzięki!
Ale szczerze mówiąc mam problem z użyciem napisanego przez Ciebie kodu. Nie korzystałem dotychczas z tak zaawansowanych funkcji programu The Bat. Od dłuższego czasu googlam, gdzie właściwie powinienem wkleić napisany przez Ciebie filtr. Pobrałem też podręcznik użytkownika z tej strony i czytam różne rzeczy o filtrach i szablonach ale nadal nie mogę dojść, co z tym zrobić. Jak właściwie tego użyć, tzn. gdzie wkleić? Proszę o wyrozumiałość smile

Dzięki!
A jeśli chciałbym zmienić wartość na inną niż różnica jednego dnia, to wystarczy, że zamienię "%_diff<>0" na np. ""%_diff<>9"?

Dzięki za odpowiedź!
Sprawa wygląda tak, że baza wiadomości o których mówię, to wszystkie moje najważniejsze maile z lat 2001-2005. Miałem je w czeluściach swojego dysku twardego razem z programem The Bat! Obecnie przenoszę je na Gmaila za pomocą folderów IMAP, ponieważ chcę mieć do nich dostęp przez sieć z dowolnego miejsca. Problem polegał na tym, że o ile w Bacie wszystko wyświetlało się dobrze, bo ustawiłem sobie sortowanie po "received" (czyli dacie pojawienia się wiadomości w skrzynce odbiorczej), to już podczas importu przez IMAP Gmail pobiera datę na nagłówków wiadomości, czyli datę "created". Problem polega na tym, że w niektórych wiadomościach data w nagłówku jest zła (nie jestem ekspertem, więc nie jestem w stanie stwierdzić dlaczego), przez co w poczacie robi się bałagan. Pomyślałem, że odszukam problemowe wiadomości i ręcznie zmienię datę w nagłówku (eksportując maila do pliku w formacie unix, zmieniając, a następnie importując znowu), jednak pozostaje jeszcze kwestia odszukania owych problemowych wiadomości i właśnie tutaj pojawił się problem, jak zrobić to nie robiąc wszystkiego na oko. Wymyśliłem sobie kilka technik wspomagania ręcznego przeglądania tych wiadomości (np. sortuję je według received i szybko przewijam obserwując czy nagle w kolumnie created nie pojawi się zupełnie inny rok - wbrew pozorom całkiem sprawnie udaje się taką różnicę wyłapać). Niemniej jednak pomyślałem sobie, że może dałoby się to jakoś zautomatyzować.

BTW
Sposób, który zaproponowałeś, czyli wyeksportowanie wiadomości, a następnie ponowne ich zaimportowanie jest przydatny w sytuacji, gdy to pole received ma złą wartość (bo wtedy The Bat po ponownym imporcie wstawia w nie wartość z created). Miałem okazję z niego kiedyś korzystać. smile

Jeszcze raz dzięki za odpowiedź i zachęcam do ewentualnych kolejnych przemyśleń!