Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "WinAPI";
Текущий архив: 2006.10.15;
Скачать: [xml.tar.bz2];

Вниз

win32 subsystem on win64, RegRestoreKey   Найти похожие ветки 

 
Ihor Osov'yak ©   (2006-05-29 23:34) [0]

хочу немного странного.. Вернее приходиться хотеть..

Нужно выполнить сабж для улея, я конечно понимаю, что это немного странно, учитывая "виртуальность" кустов 32битной подсистемы на 64 битной платформе, но все же...
При выполнении сабжа получаю GetLastError = $00000020 - аксес динайд, все права и привилегии с точки зрения win32 подсистемы установлены, пользователь имеет права админа и бакуп оператора, SE_RESTORE_NAME и  SE_BACKUP_NAME запрошены и успешно получены...

Никто не встречался с такой проблемой, или может где-то видел внятно написаное от майкрософт или других авторитетных источников что такое "низзя"? (устроит также такой вариант, подкрепленній ссілкой на первоисточник)..

Спасибо за внимание.


 
Eraser ©   (2006-05-30 01:55) [1]


> Ihor Osov"yak ©   (29.05.06 23:34)


> GetLastError = $00000020 - аксес динайд

В файле WinError код 32 вроде означает
ERROR_SHARING_VIOLATION = DWORD(32);

а вот акцесс денайд это код 5.
Т.е. скорее всего файл, с которого надо восстанавливать ключ, уже открыт.. и его или вообще не надо открывать или открывать с соответствующими ключами ShareMode.


 
Ihor Osov'yak ©   (2006-05-30 09:29) [2]

> В файле WinError код 32 вроде означает

да, сори, опячатка, неверно расшифровку не ту привел, второпях, естественно ERROR_SHARING_VIOLATION

Но. Здесь ситуация немного не та. Файл, естественно, уже открыт. Так как это реестри :-). Но. Реально подмену система делает на перезагрузке. Плюс ко всему же аналогичный код на "настоящей" 32-битной системе работает безпроблемно..


 
Чапаев ©   (2006-05-30 09:54) [3]


> а вот акцесс денайд это код 5.

Ещё со времён ДОСа... :-)


 
Ihor Osov'yak ©   (2006-05-30 10:15) [4]

ну чего пристали... после 18 часов дебага не совсем родного изделия и не такое можно написать..
Код 0x20, syserrormessage говорит "The process cannot access the file because it is being used by another process". В вопросе кроме ляпы "аксес динайд" все остальное описано корректно..


 
Eraser ©   (2006-05-30 11:39) [5]


> Ihor Osov"yak ©   (30.05.06 09:29) [2]


> Файл, естественно, уже открыт. Так как это реестри

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


 
Rouse_ ©   (2006-05-30 12:36) [6]


> The process cannot access the file because it is being used
> by another process

Ну так и пробежись по спискам открытых хэндлов - глянь кто его держит...
Может действительно залочен кем то?


 
Ihor Osov'yak ©   (2006-05-30 13:40) [7]

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

но.. все же решил проверить еще раз, а вдруг барабашки завелись...

вообщем барабашки таки завелись.. не совсем там, правда, где ожидалось..
Собственно 18 часоа преддебага было не с той проблемой, проблема упомянутая была последней каплей..
Предыстория такова - собственно это изначально был мой код, функциональный, писал его года три назад.. Но за те года три его там разные специалисты по ГУИ и дизайну переделывали не раз, после всех тех переделок снова возвратился ко мне, ибо как бы не работающий корректно под X64. Это предыстория.  А история в том, что у меня после подмены пользователь ставился в известность, что система будет перегружена и после нажатия на ок что он с этим ознакомлен - перегружалась дезусловно.. Так вот, специалисты по интерфейсу это отключили, а написали код с просьбой только перегрузить систему. когда-то..  Причем последний дизайнер умудрился сделать ошибку, вследствии которой даже это сообщение не выводилось.. :-(.  Естественно, за тех пару лет все эти ньюансы подзабылись..
 
А оказывается, что если систему не перегрузить, то все последующие операции по replaceRegKey были неуспешны (как описано выше), по той причине, что replaceRegKey помимо подмены делает и бакуп существующей версии куста, в моем случае имя файла для бакупа было всегда одинаковое (естественно разные для разных улиев). Так вот, до ребута системы бакуп файл от предыдущей операции залочен системой (даже если прибить сесию текущего пользователя).  Я не знаю, наблюдалось ли такое в чистом вин32, так как в моей изначальной версии ребут делался всегда.. Сейчас обьясняю специалистам по интерфейсу о необходимости безусловного ребута. Или хотя бы о запрете соотв. котролов, которые делают подмену после первой операции подмены и до следующего ребута..


 
Ihor Osov'yak ©   (2006-05-30 13:49) [8]

так что проблема в принципе снята, как почти всегда - возникновение спровоцировано сочетанием всяких субъективных факторов, в моем случае - умелые специалисты по гуи, не идеальная моя память на ньюансы древних проектов, усталость, инфо от тестеров что проблема наблюдается только на X64 (хотя, возможно, аналогичная проблема после изысканий дизайнеров наблюдалась и на родном 32),  етс...


 
Ihor Osov'yak ©   (2006-05-30 13:52) [9]

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


 
evvcom ©   (2006-05-30 14:26) [10]

Я обычно в таких критических местах оставляю громадные комментарии с описанием возможных проблем, если отступить от реализованного правила. Не только для будущих поколений, но и для себя же, так как через полгода уже можно не вспомнить нюансы (или во всяком случае долго вспоминать).


 
Ihor Osov'yak ©   (2006-05-30 14:50) [11]

2 evvcom,
все верно.. Но, к сожалению, не всегда получается правильно поступать.. Хотя в основном потом об этом и сожалеешь... Типа - а ежики все кололись и кололись...



Страницы: 1 вся ветка

Форум: "WinAPI";
Текущий архив: 2006.10.15;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.039 c
2-1159194607
Ega23
2006-09-25 18:30
2006.10.15
Parent PopupMenu "автоматом" - возможено?


3-1155737650
Neo Trinitron
2006-08-16 18:14
2006.10.15
Create temporary table


3-1155893152
BronOS
2006-08-18 13:25
2006.10.15
Ошибка при конвертации типов данных


2-1159431437
C@N
2006-09-28 12:17
2006.10.15
Memo и подмена символов


1-1157528777
Zilog_
2006-09-06 11:46
2006.10.15
Перевод с С на Delphi





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский