-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!news.cyf-kr.edu.pl!news.nask
.pl!news.nask.org.pl!news.unit0.net!news.glorb.com!npeer01.iad.highwinds-media.
com!news.highwinds-media.com!feed-me.highwinds-media.com!nx02.iad01.newshosting
.com!newshosting.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo
-b-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
Reply-To: "Anerys" <s...@s...pl>
From: "Anerys" <s...@s...pl>
Newsgroups: pl.misc.telefonia
References: <51cbea7f$0$1446$65785112@news.neostrada.pl>
<s...@f...lasek.waw.pl>
<156jcb7mfg2gt$.h62l9y76ui4x$.dlg@40tude.net>
<s...@f...lasek.waw.pl>
<kra664$hrn$1@node2.news.atman.pl> <krb9m7$8eu$1@node1.news.atman.pl>
<s...@f...lasek.waw.pl>
<krbghb$ff5$1@node1.news.atman.pl>
<s...@f...lasek.waw.pl>
<51d95311$0$1251$65785112@news.neostrada.pl>
<s...@f...lasek.waw.pl>
<m...@4...net>
<s...@f...lasek.waw.pl>
<m...@i...localdomain>
<s...@f...lasek.waw.pl>
<m...@i...localdomain>
<s...@f...lasek.waw.pl>
<1...@4...net>
<s...@f...lasek.waw.pl>
<1od690x24b4oh.1o80irum9of2i$.dlg@40tude.net>
<51dd48a2$0$1215$65785112@news.neostrada.pl>
<s7ewkq5ivs36$.1mifkmvc24ugv.dlg@40tude.net>
Subject: Re: Czy operator przechowuje treść smsów ?
Date: Wed, 10 Jul 2013 17:01:15 +0200
Organization: pyr pyr 40
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-Antivirus: avast! (VPS 130710-0, 2013-07-10), Outbound message
X-Antivirus-Status: Clean
Lines: 93
Message-ID: <51dd773c$0$1450$65785112@news.neostrada.pl>
NNTP-Posting-Host: 89-71-131-105.dynamic.chello.pl
X-Trace: 1373468476 unt-rea-a-01.news.neostrada.pl 1450 89.71.131.105:41210
X-Complaints-To: a...@n...neostrada.pl
X-Received-Bytes: 6283
Xref: news-archive.icm.edu.pl pl.misc.telefonia:236873
[ ukryj nagłówki ]
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:s7ewkq5ivs36$.1mifkmvc24ugv.dlg@40tude.net...
>>> del \\komputer\katalog\x*.*
>>> ... i ruch do tego komputera skacze do ~500kb/s.
>>> A pliki znikaja co sekunde jeden.
>>
>> Nie jest tak, że po każdym skasowanym pliku następuje ponowne wczytanie
>> ich
>> listy?
>
> Nie powinno, w koncu rozsadne sie wydaje ze czytamy kolejno katalog i
No właśnie...
> kasujemy kolejne pliki. Predzej bym podejrzewal ze to okienko
> eksplorera co plik dostaje sygnal "katalog sie zmienil" i go czyta aby
No i pewnie to ci robi ruch... Zawsze mi się jednak wydawało, że w systemach
do ruchu ciągłego, jakim są NT, nie powinno być aż takiej sraczki.
> aktualny wyswietlic. Dlatego robie to "w dosie". Ale idzie tak samo
> wolno jak "graficznie".
Może coś jednak jak ten eksplorer trzyma łapę na zawartości i coś się ruszy,
to zaraz czyta?
Aż się prosi o jakiegoś FileMona, czy w podobie, aby zobaczyć jaki proces i
co maca w tym czasie?
Hmm... pliki lecą do kosza? Spróbuj może wyłączyć wywalanie do Kosza?
Zobacz, czy Kosz się nie zapełnił (wtedy potrafi bardzo wolno kasować).
>
> Hm akurat cos przyblokowalo kierunek wychodzacy z tamtad ... i juz
> jest kilka sekund na jeden plik. A mialem ochote sprawdzic jak wyglada
> w zaleznosci ilosci plikow katalogu.
Ale też bym zobaczył Kosz... tak pomyślałem, że Kosz może bruździć, miałem
przypadek, że mi kasowanie szło strasznie ślamazarnie. W Koszu było od pyty
dobra wszelakiego. Zobacz, w którym koszu (TU czy TAM) to ląduje... (jeszcze
mam pewne podejrzenie, o tym za chwilę)
A skoro to jest zdalnie - czy nie następuje tu np. takie zjawisko, że
lokalnie się podaje del *.* (ścieżkę do zasobu pomijam), a przy wykonaniu
komenda jest przekładana na ciąg sekwencji wczytanie listy plików -
skasowanie wybranego (raczej pierwszy, ewentualnie ostatni) - ponowne
wczytanie listy - skasowanie - wczytanie... i tak w koło do urzygu, lub
końca.
Jeszcze jedną rzecz podejrzewam - konflikt praw dostępu (ale na poziomie
systemu operacyjnego, nie systemu plików) - Jeśli pliki są zdalnie, to
przypuszczam, że w momencie wywołania operacji plik może zostać zajęty do
jej potrzeb. A zajętego pliku skasować nie można i układ wpada w głupią
pętlę czekając na zwolnienie pliku, które nie następuje od razu, może system
wymusza w końcu jakoś jego skasowanie i przechodzi do następnego? A cała
procedura kołowania odbywa się po łączu i stąd jego dość znaczne zajęcie?
(Stąd moja sugestia, aby podpiąć monitor co, gdzie i jak rzeźbi w trakcie
operacji kasowania)
Ostatecznie któryś antywirus, który maca całe pliki już w momencie ich
dotknięcia, zanim zostanie ustalone, "czy to ten dobry dotyk"...? Także (ale
raczej nie powinno to wpływać aż tak) sprawdzanie/modyfikacja w atrybutach
czasu ostatniego dostępu, co można zresztą wyłaczyć...
Ostatecznie - silne pofragmentowanie plików na partycji, a w NTFS wszystko
jest plikiem, sama MFT trzymająca wszystko, także jest plikiem. Może
dyskowi/zasobow brakuje buforowania i do każdej operacji musi wszystko być
na nowo wczytane? Za czasów DOSa różnica w dostępie do pliku z buforowaniem
i bez, bywała kilkudziesięciokrotna...
>
>
>> Cholera... takie gdybanie jest najgorsze... A jakbyś kasował pliki nie
>> del
>
> Tak czy inaczej to tylko demonstracja ze i podstawowe operacje na
> systemie plikow mozna sp* :-(
Co by tu jeszcze spieprzyć Panowie, co by tu jeszcze... Jak śpiewa
W.Młynarski.
> A kolega chce tam miliardy zapisywac...
Sam zapis nie musi być taki tragiczny, gorzej będzie, gdy trzeba to i owo
usunąć...
Więcej pomysłów na razie mi się nie urodziło... Przyjmuję założenie, że
dyski tam i tu są OK...
Próbuję coś jeszcze wydumać, ale na razie muszę łeb ochłodzić (prawie cały
czas owiewam się wiatrakiem)...
Może ktoś ma inny pomysł, bardziej praktyczny? Chętnie i ja się dowiem :))
--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.
Następne wpisy z tego wątku
- 10.07.13 21:55 J.F.
- 11.07.13 11:39 Jarosław Sokołowski
- 11.07.13 11:40 Jarosław Sokołowski
- 11.07.13 11:42 Jarosław Sokołowski
- 11.07.13 17:53 John Kołalsky
- 11.07.13 18:40 Jarosław Sokołowski
- 11.07.13 18:41 Jarosław Sokołowski
- 11.07.13 18:49 John Kołalsky
- 11.07.13 19:04 Maciej Bebenek
- 11.07.13 19:58 Jarosław Sokołowski
- 11.07.13 21:04 Maciej Bebenek
- 11.07.13 21:54 Krzysztof Halasa
- 11.07.13 22:18 Krzysztof Halasa
- 11.07.13 22:43 Jarosław Sokołowski
- 12.07.13 20:23 J.F.
Najnowsze wątki z tej grupy
- Zegarynka w roku 1950
- Historia numeracji w polskiej sieci telefonicznej - publikacja Eugeniusza Gołębiewskiego
- Za dwa lata nie będzie wielu usług (19xxx)
- Koniec ISDN w Orange.
- Kup szybko nową ładowarkę do smartfona
- Telefonia VoIP
- "betamaxy" i inne voip-y dzisiaj
- Hackowanie SS7
- nowe spamerstwo ?
- Przychodzące impulsy telefon nie dzwoni
- Re: Zgody...
- Jak tanio dzwonic do Wielkiej Brytani?
- Chess
- Vitruvian Man - parts 7-11a
- Czas umierać.
Najnowsze wątki
- 2026-01-14 Prątki to zawalidrogi
- 2026-01-14 Naruszenie immunitetu ZP-RE Romanowskiego bezkarne (umorzenie śledztwa żurkotury)
- 2026-01-14 Prezydent Trzaskowski nie będzie mógł ułaskawić Tuska, Sienkiewicza, Bodnara, ... przed prawomocnym wyrokiem?
- 2026-01-14 Do Kongresu SZAP/USONA Złożono Proj. ,,Ustawy o aneksji i statusie stanowym Grenlandii"
- 2026-01-13 STREFA CZYSTEGO TRANSPORTU. O tym nie mówią nam WŁADZE
- 2026-01-13 To nie koniec
- 2026-01-13 Warszawa => Recruiter 360 <=
- 2026-01-13 Katowice => Key Account Manager <=
- 2026-01-13 Warszawa => Senior Backend Java Developer <=
- 2026-01-13 Wrocław => ERP Implementation Consultant <=
- 2026-01-13 Elektryk a otwieranie drzwi :-)
- 2026-01-12 Schemat automatyki
- 2026-01-12 Xiaomi [Chiny - przyp. JMJ] produkuje w całkowitych ciemnościach i bez ludzi
- 2026-01-12 Polska Grupa Zbrojeniowa (85% udziałów) Likwiduje Stomil-Poznań - Zakład Działał Od 1928r.
- 2026-01-12 Teoretyczne zagadnienie - ogrzewanie budynku




5 Najlepszych Programów do Księgowości w Chmurze - Ranking i Porównanie [2025]