From: Anatoliy Sablin 2:5020/2140.704 17 Jun 2019 08:11 +0300
To: Andrei Mihailov 2:469/335
Subject: win via usd
Hello, Andrei Mihailov. On 14.06.2019 22:00 you wrote: AM>>> Разве? AS>> Да, синхронизация данных прикладного ПО - это задача самого AS>> прикладного ПО, а не ОС. AM>>> Давай рассмотрим конкретную ситуацию. Имеем, скажем, базу AM>>> данных, открытую одним пользователем. И тут ее открывает AM>>> другой. И записывает в нее новые данные. Я правильно понял, AM>>> что они запишутся в его копию базы, а в той копии, с которой AM>>> работает первый пользователь, этих данных не будет, а второй AM>>> пользователь, соответственно, не увидит изменений, сделанных AM>>> первым пользователем после открытия файла вторым? Т.е. AM>>> одновременно будут существовать две разные версии одной базы AM>>> данных? А что произойдет, когда оба пользователя закроют свои AM>>> копии файла? AS>> В нормальных базах данных подобные ситуации разрешаются такой AS>> штукой под названием "транзакция" и различными типами блокировок AS>> (оптимистическая или пессимистическая). Однопользовательские СУБД AS>> как например SQLite позволяют работать только одному AS>> пользователю, и не дают другим подсоединиться (в sqlite, h2 AS>> создаётся файл-лок с помощью которого осуществляется AS>> блокировка). AM> Ок. А если это будет не sql, а электронная таблица, например? Не получился пример с субд, пошли перебирать другие варианты, авось что-нибудь найдётся? ;) С электронныии таблицами та же ситуация. Excel при открытии тоже блокирует файл, создавая рядом с ним файл лок, в котором ещё хранит промежуточные версии, откуда может восстановить версии файла, если текущий процесс был некорректно завершён. AS>> И я не понял, к чему были приплетены файлы AM> Потому, что изначально речь шла о множественном доступе к ним AS>> , если речь про СУБД. Если СУБД не имеет средство блокировки AS>> (блокировка файлов - это мегакостыль, от которого надо AS>> избавляться), то советую выкинуть это говно и пользоваться AS>> нормальными СУБД. AM> А в чем СУБД хранит данные, если не в файлах? В файлах. Доступ к файлам имеет только один процесс СУБД, а уже к этому процессу отправляют запросы различные клиенты, которых может быть много. Тут проблем нет. AM>>> Или такая ситуация: ты открыл... ну скажем документ в офисе и AM>>> забыл его закрыть. Затем (думая, что закрыл его) запустил AM>>> файловый менеджер и удалил его... Он удалится с диска, но AM>>> останется открытым в офисе? AS>> Да. AM>>> И что получится после закрытия офиса - файл обратно создасться AM>>> на диске? AS>> Глупый вопрос. Произойдёт ровно тоже самое, что и в случае если AS>> есть файл, офис спросит, сохранить ли изменения. Если AS>> пользователь нажмёт "да", только файл сохранится, если "нет", то AS>> не закроется без сохранения. В чём проблема? AM> Проблема в том, что если пользователь нажмет "да", то файл AM> запишется на диск, где его не должно быть - ведь пользователь его AM> уже удалил. Вот именно для этого и нужна блокировка - AM> невозможность удалить открытый файл подсказывает пользователю, что AM> сначала надо его закрыть, а потом удалять, а не наоборот. Проблемы нет. Пользователь удалил файл - файл удалился. Потом он нажал "сохранить" - файл сохранился. Да, а момент сохранения файла нет, потому что его удалили. И при сохранении можно сказать, что исходный файл удалили, что делать с этим, сохранить под новым названием, сохранить со старым названием, не сохранять. Проблемы-то нет. AM>>> А если файл очень большой и офис его подгружает по частям? AS>> Офис так не умеет, он грузит весь файл а ОЗУ. Есть даже такой хак AS>> как убить офис, создать на сетевой шаре вордовый документ с одним AS>> словом, но сделать очень большую историю изменений (можно легко AS>> таким образом увеличить размер файла до 2гб). И офис сначала час AS>> будет загрузить к себе этот документ, а потом упадёт, т. к. AS>> закончится ОЗУ. AM> Странно. Это умели делать даже допотопные вордстары и супертексты AM> в ср/м... И именно от ср/м перешла в дос и виндовс технология AM> блокировки файлов. А в современных осях этого нет и редакторы AM> вынуждены падать... Такое поведение как минимум с microsoft office 2003, грузить весь файл целиком. Ты когда офис открывал последний раз? -- Best regards! Posted using Hotdoged on Android
From: Gennadij Pastuhov 2:5036/26 15 Jun 2019 19:13 +0300
To: Sergey Bavshin 2:5020/2141.439
Subject: win via usd
Рад всех приветствовать! А особенно - Sergey! Суббота июня 15 19 18:48 Sergey Bavshin писал к Gennadij Pastuhov: SB>>>>>>>>> Сомневаюсь. В конце концов балалайкой отмахнуться можно. GP>>>>>>>> Кажется, я понял, откуда в бане возник веник. Им изначально GP>>>>>>>> комаров отгоняли. SB>>>>>>> Возможно. Но в процессе эксплуатации, у этого не хитрого SB>>>>>>> инструмента функциональность заметно расширилась. GP>>>>>> Да. А если к нему приделать круглую палку подлиннее и GP>>>>>> потолще, то бабы на неё так и начинают прыгать. SB>>>>> Бабы, они, по натуре своей, очень падки на все, что по толще SB>>>>> и по длиннее. GP>>>> За одним исключением - баб-электромонтёров я не встречал. SB>>> У нас на заводе, в службе сменного энергетикаи SB>>> электролаборатории, добрая половина женщин. А при чём тут это? GP>> Что может быть длиннее и толще, чем деревянная опора ЛЭП? SB> Например телебашня в Останкино. Нет? Слишком тонкая. SB> А деревянных опор не ставят уже лет 30+ как. Вот злодеи. ... Jonny wanna live
From: Cheslav Osanadze 2:6078/80 15 Jun 2019 11:03 +0300
To: Uncle Sasha 2:5020/2141.174
Subject: Собачьи блохи непобедимы.
Привет Uncle! 15 Июн 19 10:28, Uncle Sasha -> All: US> Ошейники покупал самые разные - им все равно. Различные блохояды лил US> на загривок - на блох впечатления не произвело. Молебен заказать? А ты их часто моешь? Собак, в смысле. Cheslav. ... Почему у вас майка нараспашку?
From: Andrei Mihailov 2:469/335 14 Jun 2019 22:00 +0300
To: Anatoliy Sablin 2:5020/2140.704
Subject: win via usd
Hello, Anatoliy Sablin. On 14.06.2019 8:18 you wrote: AM>> Разве? AS> Да, синхронизация данных прикладного ПО - это задача самого AS> прикладного ПО, а не ОС. AM>> Давай рассмотрим конкретную ситуацию. Имеем, скажем, базу данных, AM>> открытую одним пользователем. И тут ее открывает другой. И AM>> записывает в нее новые данные. Я правильно понял, что они AM>> запишутся в его копию базы, а в той копии, с которой работает AM>> первый пользователь, этих данных не будет, а второй пользователь, AM>> соответственно, не увидит изменений, сделанных первым AM>> пользователем после открытия файла вторым? Т.е. одновременно AM>> будут существовать две разные версии одной базы данных? А что AM>> произойдет, когда оба пользователя закроют свои копии файла? AS> В нормальных базах данных подобные ситуации разрешаются такой AS> штукой под названием "транзакция" и различными типами блокировок AS> (оптимистическая или пессимистическая). Однопользовательские СУБД AS> как например SQLite позволяют работать только одному пользователю, AS> и не дают другим подсоединиться (в sqlite, h2 создаётся файл-лок с AS> помощью которого осуществляется блокировка). Ок. А если это будет не sql, а электронная таблица, например? AS> И я не понял, к чему были приплетены файлы Потому, что изначально речь шла о множественном доступе к ним AS> , если речь про СУБД. Если СУБД не имеет средство блокировки AS> (блокировка файлов - это мегакостыль, от которого надо AS> избавляться), то советую выкинуть это говно и пользоваться AS> нормальными СУБД. А в чем СУБД хранит данные, если не в файлах? AM>> Или такая ситуация: ты открыл... ну скажем документ в офисе и AM>> забыл его закрыть. Затем (думая, что закрыл его) запустил AM>> файловый менеджер и удалил его... Он удалится с диска, но AM>> останется открытым в офисе? AS> Да. AM>> И что получится после закрытия офиса - файл обратно создасться на AM>> диске? AS> Глупый вопрос. Произойдёт ровно тоже самое, что и в случае если AS> есть файл, офис спросит, сохранить ли изменения. Если пользователь AS> нажмёт "да", только файл сохранится, если "нет", то не закроется AS> без сохранения. В чём проблема? Проблема в том, что если пользователь нажмет "да", то файл запишется на диск, где его не должно быть - ведь пользователь его уже удалил. Вот именно для этого и нужна блокировка - невозможность удалить открытый файл подсказывает пользователю, что сначала надо его закрыть, а потом удалять, а не наоборот. AM>> А если файл очень большой и офис его подгружает по частям? AS> Офис так не умеет, он грузит весь файл а ОЗУ. Есть даже такой хак AS> как убить офис, создать на сетевой шаре вордовый документ с одним AS> словом, но сделать очень большую историю изменений (можно легко AS> таким образом увеличить размер файла до 2гб). И офис сначала час AS> будет загрузить к себе этот документ, а потом упадёт, т. к. AS> закончится ОЗУ. Странно. Это умели делать даже допотопные вордстары и супертексты в ср/м... И именно от ср/м перешла в дос и виндовс технология блокировки файлов. А в современных осях этого нет и редакторы вынуждены падать... -- Best regards! Posted using Hotdoged on Android
From: Gennadij Pastuhov 2:5036/26 14 Jun 2019 21:39 +0300
To: Jura Bogoyavlensky 2:5020/601
Subject: Шаман из Якутии идет в Москву, чтобы очистить Россию от зла
Рад всех приветствовать! А особенно - Jura! Пятница июня 14 19 19:17 Jura Bogoyavlensky писал к All: JB> паломникоми продолжил свой путь. Он решил пройти пешком до Москвы, JB> чтобы очистить страну от зла и дать начало положительным переменам. По JB> словам шамана, он планирует добраться до столицы за два года. Все это JB> время он будет молиться, чтобы в России и в сознании людей все начало JB> меняться в хорошую сторону. Вот он - самый верный способ! ... Jonny wanna live
From: Anatoliy Sablin 2:5020/2140.704 13 Jun 2019 07:54 +0300
To: Andrei Mihailov 2:469/335
Subject: win via usd
Hello, Andrei Mihailov. On 11.06.2019 23:08 you wrote: AM>>>>> Вывод: при вытаскивании флешки без отмонтирования в винде AM>>>>> ничего плохого с ее ФС таки не происходит. AS>>>> Неправильный вывод. Чтобы получить такой вывод, тебе надо AS>>>> доказать, что при вытаскивании флешки в любых ситуациях ничего AS>>>> не произойдёт. Например, при копировании на флешку очень AS>>>> большого файла, если вытащить флешку, то тоже ничего не AS>>>> поломается. P.S.: иногда после таких выталкиваний, при AS>>>> подсоединении флешки, венда предлагает проверить её на ошибки. AS>>>> Зачем? GP>>> Намного интереснее, когда при вытаскивании-втыкании флэшки GP>>> сгорает материнка. AS>> Ага, интереснее. Наблюдал такое, когда комп уходил в AS>> перезагрузку, когда в него всовываешь флешку. AM> Т.е. флешку надо вначале смонтировать в систему, а только потом AM> втыкать в разъём??? ;))) Не понял, при чём тут монтирование. -- Best regards! Posted using Hotdoged on Android
From: Gennadij Pastuhov 2:5036/26 12 Jun 2019 14:52 +0300
To: Юрий Григорьев 2:5020/2140.2
Subject: win via usd
Рад всех приветствовать! А особенно - Юрий! Вторник июня 11 19 16:07 Юрий Григорьев писал к Cheslav Osanadze: ЮГ> Я вот уже который год как лето-жара, о кондее мечтаю. Hо финансы всё ЮГ> время на более другие цели приходится тратить... :((( Пиздец какой-то, в Сибири хотят кондей! Помню, в том году в конце ноября приехали в Дубаи, зашли в номер отеля - там жуткий холод, где-то +22, хотя на улице было под +27. Кое-как допёр как вырубить кондей, к вечеру прогрелось до забортной, стало очень комфортно :) ... Jonny wanna live
From: Cheslav Osanadze 2:6078/80 12 Jun 2019 12:02 +0300
To: All
Subject: Принцесса
Привет All! Сабж возвращается! В новой реинкорнации ============== Кому: Уважаемый бенефициар, Электронная электронная служба уведомлений Объединенного банка Африки (UeNS) Мы пишем, чтобы уведомить вас о том, что мы получили обязательное уведомление от Международного валютного фонда (МВФ) в сотрудничестве со Всемирным банком о переводе вашего фонда, что было необоснованно задержано некоторыми банками и незаконными органами. Офис МВФ поручил нашему банку перевести вам _ 500 000,00 с помощью международных дебетовых карт банкоматов в качестве компенсационного фонда для вашей прошлой транзакции, которую вы унаследовали на законных основаниях и по той или иной причине вам было отказано в выдаче. ============= После предыдущего потока писем - грохнул кризис, с обвалом курса.... Cheslav. ... Милиционерам выдали автоматы чтобы у них не отняли пистолеты.
From: Юрий Григорьев 2:5020/2140.2 11 Jun 2019 15:17 +0300
To: Andrew Lobanov 2:5020/2141.206
Subject: win via usd
Привет, Andrew! 11 июня 2019 в 14:10 ты писал(а) для Cheslav Osanadze : ======================================================= CO>>>>> Я вот пожалуй соглашусь, что бэкапить работающую систему как CO>>>>> то не то. ЮГ>>>> А какую систему надо бэкапить - которая начала глючить? :)) AL>>> Hезапущенную. CO>> Вот и я так подумал и убил Акронисовский планировщик сразу. лучше я CO>> раз в неделю перезагружу комп и нажму F11. Так вернее. AL> В современных системах всё сложнее контролировать изменения на AL> системном разделе. Особенно в Windows. В MacOS не знаю, так как не AL> пользовался ей. В линуксах и прочих BSD просто. А бекап во время работы AL> такой неконтролируемой системы потенциально чреват нарушением AL> целостности данных. Шанс не такой уж и большой, но раз уж мы делаем AL> резервную копию, то стоит учесть максимум всего, чтобы она была AL> рабочей. А ты не думал, что разработчики Акрониса специально учли этот момент? И изменяющиеся разделы просто не копируются во время изменения? Сколько раз снимал образы, всегда были рабочие. Десятки, а может сотни раз. ======================================================= Юрий Григорьев.
From: Dmitri Kamenski 2:5023/24.1 11 Jun 2019 10:58 +0300
To: Cheslav Osanadze 2:6078/80
Subject: win via usd
Hi Cheslav! 11 июня 2019 08:42, Cheslav Osanadze писал Dmitri Kamenski: DK>>>> Буханка на личном примере: https://www.kp40.ru/news/kp/22251/ ЮГ>>> Во-первых, в списках тебя не обнаружил. DK>> Там не полный список сочувствующих ;-) ЮГ>>> во-вторых, с каких пор радиатор находится под днищем??? O_O DK>> С тех пор как в буханке снятие\установка двигателя, коробки и DK>> сопутствующих элементов производится из кабины. CO> Иных УАЗов мне не попадалось, движок всегда в салоне, но везде CO> радиатор - спереди. Но добраться до него проще из-под днища. Bye Cheslav!