Тем временем у меня второй раз за 2 месяца винда из дуалбута ломает собственную ntfs.

// Теперь это ненависти к M$ тред.

Код в студию. Почему не работает, какие ошибки?

винда из дуалбута ломает собственную ntfs.

может банально диск осыпается или электрик рубильником баловался? нтфс хоть и тормоз, но надежен

Код в студию. Почему не работает, какие ошибки?

Да пожалуйста :-)

DirectorySearcher ds = new DirectorySearcher(ent, userFilter, fields.ToArray(), SearchScope.Subtree);
ds.PropertyNamesOnly = true;
logger.Log(new LogEvent("Fecthing " + userBase));
SearchResultCollection sc = ds.FindAll();
foreach (SearchResult sr in sc) {
	DirectoryEntry de = sr.GetDirectoryEntry();
	logger.Log(new LogEvent("   Got " + de.Path));
	foreach (string pn in de.Properties.PropertyNames) {
		try {
			foreach (object v in de.Properties[pn]) {
				if (v!=null) {
					logger.Log(new LogEvent("      " + pn + "=" + v.ToString()));
				} else {
					logger.Log(new LogEvent("      " + pn + "=NULL"));
				}
			}
		} catch (Exception x) {
			logger.Log(new LogEvent("      " + pn + "=EXCEPTION"));
			logger.Log(new LogEvent(x));
		}
	}
}

Почему не работает? Потому что у индусов из МС руки из ж..пы.

Какие ошибки? Тривиально - например, атрибуты cn,sn,uid,givenname читаются нормально, а при попытке чтения атрибутов homeDirectory, loginShell, udiNumber, gidNumber и многих-многих других выскакивает чрезвычайно информативный стектрейс:

System.Runtime.InteropService.COMexception (0x8000500c)
   in System.DirectoryServices.PropertyValueCollection.PopulateList()
   in System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   in System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   in ... тут уже адрес моего кода

Ну разве это не чЮдесно?

может банально диск осыпается или электрик рубильником баловался? нтфс хоть и тормоз, но надежен

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

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

Тем времен debian на соседнем разделе никаких проблем не видит

т.е. диск целиком ты так и не проверил?

А может, у тебя вина не выключается а хибернейтится

Пуск-Выключение-Кнопка с красной фиговиной.

В смысле? SMART говорит, что все нормально, а chkdsk /f пришлось делать с флешки, на которой уже с прошлого раза стоит BartPE

Возможно драйвер IDE/AHCI-контроллера говно и бьёт ФС. Сталкивался пару раз с такой фигней при починке компов.

может банально диск осыпается или электрик рубильником баловался? нтфс хоть и тормоз, но надежен

Нет, у меня тоже такое было. В семёрке есть бага (наверно, уже закрытая), благодаря которой падал NTFS.

MHDD, Victoria

homeDirectory, loginShell, udiNumber, gidNumber

а версии AD'а совпадают? у них вообще атрибуты такие есть? насколько помню это появилось в 2003 с дополнением для поддержки UNIX

Честно говоря, я был об MS намного лучшего мнения :-(

Такой большой, а в сказки веришь....

/извинити, не удержался...

а версии AD'а совпадают?

Коннект идет не к серверу AD, а к 389 directory server, вообще-то. Причем к одному и тому же серверу. Я же говорю, ВСЁ одинаковое: один и тот же сервер LDAP, одни и те же параметры подключения, одна и та же версия NET Framework, отличаются только операционки.

Да без проблем. Я конечно наступал на подобные грабли в жабе, но там они были только в случае, если использовались вызовы адресованные к native-коду.

Проблема как всегда в кривизне рук. Только на этот раз «индусятьих» (так называют индусов, которые работают в MS)

Если в жабе мы знаем, что программа будет одинаково работать на всех ОС

То мы с жабой не работали, иначе были бы в курсе, что это далеко не так.

Неавторизованное чтение из ldap?

The .NET Framework does not support all versions of every platform.

По-моему, этой фразой все сказано, а дальше начинаются пляски, вот эта часть не работает на XP до sp3, а вот эта работает, etc

а при попытке чтения атрибутов homeDirectory, loginShell, udiNumber, gidNumber и многих-многих других выскакивает чрезвычайно

В порядке любопытства, эти «и многих-многих других» тоже имеют большую букву в имени?

System.Runtime.InteropService.COMexception

COMexception

COM

Судя по всему, различается версия и, соответственно, реализация некоторых внутренних, независящих от дотнета механизмов взаимодействия с AD у Win7/2008 и WinXP/2003, что, впрочем, неудивительно.

Кстати говоря, поиск по «DirectoryServices COMexception» показывает, что проблема с этим компонентом довольно частая.

Wow!

В порядке любопытства, эти «и многих-многих других» тоже имеют большую букву в имени?

Не обязательно. К тому же, атрибу «givenName» (да-да, тоже с большой буквой в середине) фетчится нормально :-)

Неавторизованное чтение из ldap?

Почему «неавторизованное»? Аутентификация пройдена, ACL'ями явно привилегии розданы, к тому же, опять так, в Win7 всё работает как положено.

Почему «неавторизованное»?

Не вижу в коде.

в Win7 всё работает как положено.

Разница, подозреваю не в ОС, а в отношениях между AD и двумя машинами.

В гугл пробовали забивать, там ведь наверняка ответ есть?
«System.Runtime.InteropService.COMexception»
".net"
«ldap»
можно еще опционально «ad»

Ну на самом деле тут вина не .NET, а ADSI. Просто в разных ОС аттрибуты мапятся на якобы LDAP по разному. Типа ORM на уровне ОС разный.

Не вижу в коде.

Кусок который задает корневой элемент поиска в оригинале есть, просто в цитате его нет. Там делается plain-аутентификация.

а в отношениях между AD и двумя машинами.

Нет. Никакого. AD. Это четыре standalone-хоста: LDAP-сервер на линуксе, standalone 2003, standalone XP и standalone Win7. Нет никаких «отношений» между ними кроме как обычного TCP/IP взаимодействия.

В гугл пробовали забивать, там ведь наверняка ответ есть?

Ответа на этот вопрос там нет. И опять таки, проблема крайне специфичная - кому из тут отметившихся (кроме меня) вживую доводилось работать с LDAP (не с AD, именно с LDAP!!!) из .NET с WinXP или 2003-сервера, не включенного в домен? :-)

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

Я думал, NTFS3g давно уже отказывается монтировать раздел, если на него был произведён hibernate.

Проверь, корректно ли установлены библиотеки для работы с AD. Особенно если XP не professional SP3.

И опять таки, проблема крайне специфичная - кому из тут отметившихся (кроме меня) вживую доводилось работать с LDAP (не с AD, именно с LDAP!!!) из .NET с WinXP или 2003-сервера, не включенного в домен? :-)

Это характерно для винды, чуть вправо-влево от привычного использования и немедленно возникают какие-то странные грабли.

Это четыре standalone-хоста: LDAP-сервер на линуксе

Кхы-кхы, а может быть из-за этого на самом деле все?

А почему ты решил, что «только стандартная библиотека фреймворка» не вызывает нативных функций?

А на Linux оно тоже не будет работать - надо ещё на GTK# написать бэкэнд.

только стандартную бибилиотеку фреймворка

А что это такое за «стандартные библиотеки» с com interop-ом? Мало ли какой com-ерунды у тебя ни стоит на разных машинах.

А на Linux оно тоже не будет работать - надо ещё на GTK# написать бэкэнд.

Вообще-то, оно работает на Linux. Под Mono. Полностью, так же как и на «семерочке» и лучше чем на ХэПэ.

И «бэкэнд» (хотя правильней писать frontend!!!) написан на Windows Forms.

А что это такое за «стандартные библиотеки» с com interop-ом?

А то, что это ent из примера кода это

System.DirectoryServices.DirectoryEntry(«LDAP://hostname/path»,userdn,bindpw);

Чей синтаксис и поддержка этого URL задекларированы в MSDN.

Так что да, это именно стандартная бибилиотека платформы .NET

> Это четыре standalone-хоста: LDAP-сервер на линуксе
Кхы-кхы, а может быть из-за этого на самом деле все?

Не в этом. Потому как тогда «это» не работало бы и в Win7 и Win2008. А в последних двху оно работает. Упс?

А почему ты решил, что «только стандартная библиотека фреймворка» не вызывает нативных функций?

Да я даже знаю что она их вызывает. Вот только дело в том, что она судя по всему криво их вызывает :-)

Проверь, корректно ли установлены библиотеки для работы с AD

Читай выше. Нет никакого AD. Вообще. Это отдельно стоящий сервер LDAP.

Особенно если XP не professional SP3.

XP. SP3. И Win2003 со всеми апдейтами (специально поставил все апдейты которые WindowsUpdate предложил). Результат не изменился :-)

0x8000500c

The Active Directory Datatype Cannot be Converted to/from a Native DS Datatype

Особенно если XP не professional

То есть, в Home Edition даже совместимость сломана? Это даже поинтереснее, чем невозможность сменить обои в Starper.

Тогда проверяй, что твой LDAP сервер соответствует представлениям MS о LDAP сервере, то бишь AD. Выше написали про «The Active Directory Datatype Cannot be Converted to/from a Native DS Datatype» вполне возможно что под это дело придётся писать воркэраунд.

З.Ы. сообщения об ошибках в COM - отдельная печальная история...

В Home edition что-то мутилось с возможностью работы с AD. Я только не знаю, было ли это только на уровне UI или и на уровне библиотек тоже.

Настало время выкинуть .NET.

Они частично забили на совместимость ещё, где-то на уровне WinVista и совершенно забили на совместимость в случае WM -> WP. Доброе утро! :)

Не верю.

может банально диск осыпается или электрик рубильником баловался? нтфс хоть и тормоз, но надежен

Последний раз я долго пользовался Windows'ом во времена Windows XP SP1 или SP2. Не могу сказать, что NTFS надёжна.

А есть варианты на сегодняшний день? Насколько я помню, M$ поддерживает только fat`ы, которые не жрут больше, чем 3.5 Гб и NTFS, который ломается. Так что выбора нет.

Криво если только в том смысле, что забили на поддержку obsoleted интерфейсов. Выбросили проверки «если у нас не система, а говно мамонта, надо стиснуть зубы и работать с двойным тщанием».

UDF, но на него систему не поставить.