Спецам по теории вероятности

если считать по практике, то скорее всего 100% бо кто-то забудет правильно выставить TZ.

// wbr

хм... какая-то сложная задача.

на диске виндовс будет точность в 2 раза меньше. т.е. есть вероятность, что файл создан в момент м+1, а на виндах штамп стоит м - переписываем.

снова сравниваем: м+1 и какой-то другой штамп н > м+1 снова переписываем?

половина: или перепишет или нет

вероятность = 0

Специалисты обращают внимание, что дисциплина называется "теория вероятностей".

Не совсем понятно, что за точность упомянута. Точность значения, которое передают в ядро? Или способ кодирования даты?

Для нормального ответа надо знать три вещи:

* с какой точностью дата хранится сама по себе.

* как они сравниваются (происходит ли "округление", как именно выполняется).

* какой закон распределения у упомянутых величин. пока даны только цифры 1 и 2 с, если это вообще о том.

Когда всё будет известно, дать ответ будет плёвым делом.

вспоминается анекдот: какова вероятность встретить на улице динозавра?

50%. Почему? Или встречу, или не встречу.

Между прочим это реальная задача.

Что значит точность - это надо додумать:

Время    Linux   Windows

0.1       0        0
0.9       0        0
1.2       1        0
1.9       1        0
3.0       3        2
4.2       4        4
5.5       5        4
3.4       3        2
7.8       7        6


Привыкли шаблонные ("типовые") задачи решать?
 

А как время распределено?

Вообще никто не знает.

И почему не прозвучал вопрос - что значит вероятность?

Если после прохождения курса (любого) вам всё ясно - значит, зря время потратили.

Не знаю как в вашем мире, но в моём, на участке [a,b], время распределено равномерно.

получается если t - реальное время изменения файла, то в linux его время - [t], в windows - [t]-[t mod 2]

из этого следует, что вероятностное пространство описывается интервалом [ [t],[t]+2 ], т.е. [0,2]

а файл копируется, если время попадает в [1,2]

т.е. вероятность равна, как уже правильно заметили 0.5

мне кажется, что даже если мои выкладки неверны, то по теореме Бернулли всё это сойдётся к 0.5 (можно смоделировать и посмотреть)

немного не правильно свою мысль выразил. вероятность сойдётся к 0.5 => по теореме Бернулли она реально равна 0.5

>Между прочим это реальная задача.

Рад за тебя. Тогда и подходи к делу серьёзно, см выше.

>Что значит точность - это надо додумать:

Если что-то надо "додумать" -- то это не реальная задача. Ибо ответ будет справедлив для "додуманной" системы, не для реального объекта.

>Время Linux Windows

Вон, даже данные какие-то есть. Вот и попробуй ответить на три вопроса, прозвучавшие ранее. Ничего другого для решения не потребуется.

>Привыкли шаблонные ("типовые") задачи решать?

Привыкли решать задачи, а не фантазировать попусту. А задачка детская сама по себе.

>А как время распределено?

Самый важный вопрос, на самом деле.

>Вообще никто не знает.

Да уж. Великая Тайна -- как там у вас время распределено. Оцени по данным -- выше же выкладывал чего-то. Без этого не решишь.

>И почему не прозвучал вопрос - что значит вероятность?

Потому что определение вероятности, в отличии от исходных данных этой задачи, есть в букваре.

>Если после прохождения курса (любого) вам всё ясно - значит, зря время потратили.

Если человек знает, как сложить два числа -- он лох.

Задача, повторюсь, детская. Но разобраться с распредлением и прочим надо.

Да эти условия (от нуля до 1, от нуля до 2) ни о чём не говорят сами по себе.

Допустим, в линуксе 99% дат будет ложиться близко к 1. И всё, сбоев почти не будет.

Равномерность тут за уши притянута, не откуда ей взяться.

вы не путайте реальный мир со сферическим конём в вакууме.

я даже себе представить не могу при каких условиях распределение времени создания файлов может быть не равномерным.

имеется в виду распределение t - ([t]-[t mod 2])

Если осознанно игнорировать всякие фазы луны, и считать что вероятность изменения файла на линуксе в четную и нечетную секунду, из соображений симметрии, одинаковая, то получается что искомая вероятность - 0.5

Численно учесть всякие экстры, типа того, что при синхронизации Win->Linux на линухе файлы с четной датой модификации получат перевес, не представляется возможным - недостаточно данных

>вы не путайте реальный мир со сферическим конём в вакууме.

>я даже себе представить не могу при каких условиях распределение времени создания файлов может быть не равномерным.

Тут надо разобраться, откуда задержка берётся. Например, ядро тормозит, обрабатывая всякое. Вот и результат. Откуда тут равномерности взяться? В реальном мире её вообще тяжело встретить.

Хотя сам тамошние процессы не представляю, утверждать, что всё именно так, не буду.

По данным сразу видно будет, попусту "философствовать" незачем.

> я даже себе представить не могу при каких условиях распределение времени создания файлов может быть не равномерным.

- Синхронизация Win->Lin или монтирование FAT-накопителей и копирование оттуда.

- [не имеет значения для задачи но все же] во времена win9x были вирусы, которые ставили у зараженных файлов время в 62 секунды. На некоторых машинах распределение даты у файлов было *очень* неравномерным :-)

>Откуда тут равномерности взяться? В реальном мире её вообще тяжело встретить.

ради интереса посчитал эмпирическую функцию распределения последних двух секунд создания файлов на своём диске.

в миллисекундах от 0 до 2000 соответственно.

http://img110.imageshack.us/img110/3820/ecdfyy6.png

тут и специалистом не надо быть чтобы точно сказать что это за распределение.

считал под виндой, линукса под рукой нет.

>ради интереса посчитал эмпирическую функцию распределения последних двух секунд создания файлов на своём диске.

>в миллисекундах от 0 до 2000 соответственно.

ничего не понимаю. видимо, чтобы постичь это, нужны Тайные Знания о Глубинном Устройстве Виндося. или Линупся.

поделись, как это вообще считают (в смысле "реальное время"). хочу у себя попробовать.

using System;
using System.Collections.Generic;
using System.Text;
using System.IO;

namespace hist
{
    class Program
    {
        static void calctime(DirectoryInfo dirname, StreamWriter w)
        {
            try
            {
                FileInfo[] fi = dirname.GetFiles();
                foreach (FileInfo f in fi)
                {
                    int mls = ((f.CreationTime.Second % 2) * 1000 + f.CreationTime.Millisecond);
                    if (mls == 0 || mls == 1000) continue;
                    w.WriteLine(mls);
                }
                DirectoryInfo[] di = dirname.GetDirectories();
                foreach (DirectoryInfo d in di)
                    calctime(d, w);
            }
            catch
            {
            }
        }

        static void Main(string[] args)
        {
            string[] strDrives = Environment.GetLogicalDrives();
            DirectoryInfo dir = new DirectoryInfo(strDrives[0]);

            StreamWriter w = new StreamWriter("stat.txt", false, Encoding.UTF8);

            try
            {
                DirectoryInfo [] dirs = dir.GetDirectories();
                foreach (DirectoryInfo d in dirs)
                    calctime(d,w);
            }
            catch
            {
            }
            w.Close();
        }
    }
}

хотя я что-то усомнился откуда винда знает миллисекунды, в msdn ничего по этому поводу не написано.

мистика:)

> ради интереса посчитал эмпирическую функцию распределения последних двух секунд создания файлов на своём диске.

> в миллисекундах от 0 до 2000 соответственно.

> http://img110.imageshack.us/img110/3820/ecdfyy6.png

> тут и специалистом не надо быть чтобы точно сказать что это за распределение.

Давай график шириной в 2000 пикселей... может тут все значения - нечетные, а мы этого не видим!

наугад из файла stat.txt вырезал

243 243 243 259 290 306 306 306 321 321 321 321 337 337 337 353 981 406 1006 1376 61 1391 1578 1641 1812 1875 1921 311 327 452 467 436

и вообще, причём здесь чёт/нечёт

> наугад из файла stat.txt вырезал

> 243 243 243 259 290 306 306 306 321 321 321 321 337 337 337 353 981 406 1006 1376 61 1391 1578 1641 1812 1875 1921 311 327 452 467 436

не понял? что эти числа значат? число файлов с датой в n, n+1, ... милисекунд?

> и вообще, причём здесь чёт/нечёт

Ну, если у тебя у всех файлов в дате создания число милисекунд четное, то распределение явно не равномерное.

это

(f.CreationTime.Second % 2) * 1000 + f.CreationTime.Millisecond

тоесть если файл создался в 10:23 35.453

то значение 1453.

Ok, тогда гипотезу о только-четных-числах можно отбросить :-)

>(f.CreationTime.Second % 2) * 1000 + f.CreationTime.Millisecond

Так это ж тупо последние знаки в записанном времени создания. Ясен пень, эта величина равномерно распределена на интервале [0,2). А делил бы на 5 -- было бы то же самое на интервале [0,5).

Надо брать разность между "записанным временем создания" и "настоящим временем", как в табличке топикстартера. И глядеть, как она себя ведёт.

Кстати, я тут файлы покопировал -- время идентично, безо всяких поправок. Что-то делаю не так:

$ touch file $ cp --preserve=all ./file ./file2 $ ls --full-time ./f* .. 2008-01-14 10:58:41.000000000 +0700 ./file .. 2008-01-14 10:58:41.000000000 +0700 ./file2

В общем полностью перестал понимать условия и суть задачи.

>(f.CreationTime.Second % 2) * 1000 + f.CreationTime.Millisecond

Так это ж тупо последние знаки в записанном времени создания. Ясен пень, эта величина равномерно распределена на интервале [0,2). А делил бы на 5 -- было бы то же самое на интервале [0,5).

Надо брать разность между "записанным временем создания" и "настоящим временем", как в табличке топикстартера. И глядеть, как она себя ведёт.

Кстати, я тут файлы покопировал -- время идентично, безо всяких поправок. Что-то делаю не так:

$ touch file

$ cp --preserve=all ./file ./file2

$ ls --full-time ./f*

.. 2008-01-14 10:58:41.000000000 +0700 ./file

.. 2008-01-14 10:58:41.000000000 +0700 ./file2

В общем полностью перестал понимать условия и суть задачи.

нет.

кстати с чего вдруг топикстартер решил что

>Точность хранения времён изменения файла в операционных системах Linux и Windows равны соответственно 1с и 2с.

я уже спать хочу и мало чего понимаю, поэтому из дискусси ухожу.

на самом деле нужно просто взять тестовый массив и посмотреть сколько файлов перезапишется. потом поделить на все синхр. файлы. это, как я уже говорил и будет вероятность. и в топку, к очкастым преподам всю это теорию

+1

> Тут надо разобраться, откуда задержка берётся

> Точность ХРАНЕНИЯ ...

> кстати с чего вдруг топикстартер решил что

Хорошо, Не Виндовс, а FAT:

Навскидку - http://www.osp.ru/win2000/2006/06/3266197/

Если вашей задачей является копирование с систем Windows на устройства сетевого хранения (NAS), придется выяснить у поставщика вашего устройства NAS, поддерживает ли это устройство временные стандарты NTFS-файлов. Ключ Robocopy /FFT особенно полезен, если имеется устройство NAS, которое не поддерживает 100-наносекундную точность при определении времени создания файла в NTFS, а использует только двухсекундную точность определения времени создания файла, характерную для FAT. Округление времени создания NTFS-файла может привести к копированию файлов, которые не изменялись. Robocopy распознает эти файлы как новые либо как старые, но измененные и запускает операцию копирования.

Переключатель /FFT заставляет Robocopy использовать точность определения времени, применяемую в FAT, т. е. утилита использует двухсекундный стандарт для сравнения файлов. Пока файлы имеют одинаковые временные отметки внутри двухсекундного интервала, Robocopy считает их идентичными и не копирует. Этот переключатель значительно снизит время копирования и сократит случаи копирования файлов, которые в действительности не изменялись.

Насчёт Линукса не уверен - где-то читал.

А вообще, проблема открылась при резервном копировании огромного числа файлов с помощью rsync:

При копировании на FAT32 (так надо) копировалось гораздо большее число файлов,чем на reiserfs с одного и того же источник; по ощущениям - все!

Надо бы провести опыт, и по теории оценить точность в линуксе ;-)

А когда они один раз синхронизируются с винды на линукс, распределение времени создания получится с перекосом в сторону виндового. Так что при последующих проходах будет копироваться меньше тех файлов, которые копировать не надо.

А по-моему, вы тут фигнёй страдаете с распределением времени. Считайте тот же sha1, сравнивайте старый/новый, если изменился, копируете. И нефиг доли секунд считать, если в сети, всё равно время может сбитое быть на всех машинах.

> Считайте тот же sha1, сравнивайте старый/новый,
Более двух миллионов файлов. Ага =)

> всё равно время может сбитое быть на всех машинах.
Время копии файла устанавливается программой (rsync), и её глубоко всё равно какой год на машине.

Собственно, меня интересовал вопрос - почему на FAT копируются практически всё файлы. С чем это связано? Я догадался о точности хранения времени. Далее нужно было теоретическое обоснование. И наконец численная проверка теории и эксперимента (которая пока не состоялась) =)

Ты лучше скажи, снес ты уже FAT или нет?

Нет. Это резервная копия, которая должна читаться по Оффтопиком. И писаться под линуксом =)

Тогда проверяй время модификации и записывай его в отдельный файл. Ну или поставь, наконец, нормальную бекапилку.

> Более двух миллионов файлов. Ага =)

у тебя два миллиона файлов обновляются с интервалом 1с 2с ?

> Тут надо разобраться, откуда задержка берётся

> Точность ХРАНЕНИЯ ...

Сразу было подозрение, что задача всплыла из глубин чьего-то больного воображения. По ходу треда только убеждаюсь в этом. На вот, погляди, чего "на практике" делается, раз теория не нравится:

$ cat ./script
#!/bin/bash

#Скрипт для проверки ужасов fat.

n=10000

for ((i=0; i<n; i++))
do
echo "ы" > ~/file1
cp --preserve=timestamps ~/file1 ./file2
[ ~/file1 -nt ./file2 ] && echo "+"
[ ~/file1 -ot ./file2 ] && echo "-"
done

$ sudo ./script
$

Не наблюдаю стройных рядов плюсов и минусов. Может мало тестов зарядил? Поставь у себя пару миллионов, выложи результат.

И да, это на фате работало. А ~ на ext3. Так что выброси свою никчёмную настройку над cp в мусорницу, тебя разводят.

>нет.

Что "нет"? Про твой код? Да, он погоду показывает.

>кстати с чего вдруг топикстартер решил что

>>Точность хранения времён изменения файла в операционных системах Linux и Windows равны соответственно 1с и 2с.

Я подозреваю, что ему об этом рассказали люди, которые за деньги "помогают решить эту проблему".

Ну не может быть, чтобы в винде всё было настолько хреново само по себе. Явно "ынтерпрайз-разработчики" руку приложили.

>и в топку, к очкастым преподам всю это теорию

Конечно "в топку". Вот когда у "умных студентов" нихрена не будет работать из-за непонимания сути проблемы, тогда можно будет вспомнить, чего там говорили "очкастые преподы". А заранее нафига думать?