Комментарии 19
Вы дали первый минимум информации и предложили сделать выбор. А реально сделанный выбор был сделан на гораздо большем массиве исходной информации, и из этого массива совершенно очевидно, что нужно сделать (ну, скажем, если некоторые устройства зависают — выбора просто нет).
это перевод
между первым и вторым постом прошло полгода, на момент первого решения еще не было, так что все честно
Смысл был не в том, чтобы угадать правильный ответ, а в том, чтобы подумать на эту тему
между первым и вторым постом прошло полгода, на момент первого решения еще не было, так что все честно
Смысл был не в том, чтобы угадать правильный ответ, а в том, чтобы подумать на эту тему
ну и конечно в том, чем в реальной жизни приходится жертвовать ради обеспечения совместимости, даже msft:)
в реальной жизни протоколы надо разрабатывать с расчётом на то, что придётся подстраиваться под конкретные реализации, поэтому нужны средства их идентификации
в реальной жизни приходится считаться с тем, что было разработано 20 с лишним лет назад ( не одной msft кстати, а еще IBM, Intel и 3Com) и иметь дело возможными неправильными решениями.
сказать постфактум что протокол плох — это очень легко, но никакого смысла для реальности не имеет не имеет
сказать постфактум что протокол плох — это очень легко, но никакого смысла для реальности не имеет не имеет
Насчет невозможно забрать — почему бы не посылать SHChangeNotify с флагом SHCNE_UPDATE в момент получения ошибки? Это заставит WE инвалидировать рабочую область и вновь запросить EnumObjects. А между отправкой ChangeNotify и новым EnumObjects мы установим флаг, который запрещает работать по быстрому протоколу. Единственная проблема — мигание окна при первом запросе.
ИМХО, надо было просто добавить чекбокс «включить быстрый режим» в свойства сетевого диска. И по умолчанию сделать этот чекбокс выключенным. И дать ссылку в хелпе на КВ с известным списком плохих устройств.
Фигня полная.
В первом посте Вы написали решение: «отключить быстрый режим по умолчанию». И все пользователи будут чмырить висту за тормоза и восхвалять другие ОС, которые используют быстрые запросы.
1. Написав правильное решение, Вы написали что оно не подходит.
А некоторые здесь пытались решить эту задачку логически. Разве это честно?
2. Если другие ОС используют быстрые запросы, значит, они точно так же могут повесить файловый сервер. Одну из фраз можно будет перефразировать: «Ох, опять кто-то принес на работу свой ноутбук с Ubuntu и включил его в корпоративную сеть. Наш файловый сервер опять упал.»
В первом посте Вы написали решение: «отключить быстрый режим по умолчанию». И все пользователи будут чмырить висту за тормоза и восхвалять другие ОС, которые используют быстрые запросы.
1. Написав правильное решение, Вы написали что оно не подходит.
А некоторые здесь пытались решить эту задачку логически. Разве это честно?
2. Если другие ОС используют быстрые запросы, значит, они точно так же могут повесить файловый сервер. Одну из фраз можно будет перефразировать: «Ох, опять кто-то принес на работу свой ноутбук с Ubuntu и включил его в корпоративную сеть. Наш файловый сервер опять упал.»
>Борьба с этим багом, на самом деле, продолжалась несколько месяцев. За это время было обнаружено еще множество устройств, которые неправильно работали в «быстром» режиме.
а ведь всей этой проблемы вообще не было, если бы ms имела программу сертификации, давала спеки вендорам, желающим сделать свою реализацию сервера и потом сама же тестировала эти железки за деньги.
а ведь всей этой проблемы вообще не было, если бы ms имела программу сертификации, давала спеки вендорам, желающим сделать свою реализацию сервера и потом сама же тестировала эти железки за деньги.
Прикинь, все так и есть, и программа сертификации, и спеки вендорам. Но она же не может заставить всех проходить эту сертификацию.
после скольких лет судеьных разбирательств проект samba получил спеки за десять тыщь евро? мне кажется, это произошло все пару лет назад.
и ссылочку на программу сертификации собственных реализаций самбы мне дайте, будьте добры
и ссылочку на программу сертификации собственных реализаций самбы мне дайте, будьте добры
однако вы меня определенно обманываете — обсуждаемый баг [1] был обнаружен в начале 2006го, за два года до того, как samba project получили спеки[2]
[1] https://bugzilla.samba.org/show_bug.cgi?id=3526
[2] www.linux.com/archive/feed/123721
[1] https://bugzilla.samba.org/show_bug.cgi?id=3526
[2] www.linux.com/archive/feed/123721
У меня от этой пары утверждений лёгкий когнитивный диссонанс:
Я таки не пойму, как связаны CIFS и локальные диски. Это если вдруг кто-нибудь будет просматривать список файлов своей машины через сетевой диск?
По поводу определения ошибочного драйвера, протокол CIFS (он же SMB) не дает клиенту достаточно информации, для того, чтобы определить, какая версия стоит на сервере.
Таким образом, решение было принято такое: перестать использовать «быстрые» запросы для чего-либо иного, кроме локальных дисков.
Я таки не пойму, как связаны CIFS и локальные диски. Это если вдруг кто-нибудь будет просматривать список файлов своей машины через сетевой диск?
Даже чекбокс поленились сделать, хорошо ещё если ключик в реестре оставят для гиков, ато ведь этими совместимостями можно в каменном веке остаться )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как бы вы решили такую проблему совместимости? Ответ