Win32 subsystem on win64, RegRestoreKey
хочу трохи дивного.. Вірніше доводиться хотіти..
Потрібно виконати сабж для вулика, я звичайно розумію, що це трохи дивно, враховуючи "віртуальність" кущів 32-бітної підсистеми на 64-бітній платформі, але все ж таки. При виконанні сабжа отримую GetLastError = $00000020 - аксес динайд, всі права та привілеї з точки зору win32 підсистеми встановлені, користувач має права адміна та бакуп оператора, SE_RESTORE_NAME та SE_BACKUP_NAME запросені та успішно отримані.
Дякую за увагу.
а ось акцес денайд це код 5. Тобто. швидше за все файл, з якого треба відновлювати ключ, вже відкритий. і його або взагалі не треба відкривати або відкривати з відповідними ключами ShareMode.
> У файлі WinError код 32 начебто означає
так, сміття, опівка, неправильно розшифровку не ту привів, поспіхом, звичайно ERROR_SHARING_VIOLATION
Але. Тут ситуація трохи не та. Файл, звісно, вже відкрито. Тому що це реєстри :-). Але. Реально заміну система робить на перезавантаженні. Плюс до всього ж аналогічний код на "справжній" 32-бітній системі працює безпроблемно.
> а ось акцес денайд це код 5.Ще з часів ДОС. :-)
ну чого причепилися. після 18 годин дебагу не зовсім рідного виробу і не таке можна написати. Код 0x20, syserrormessage каже: "Підпис не може бути використаний в файлі тому що він буде використаний за будь-який процес". У питанні крім ляпи "аксес динайд" все інше описано коректно.
> Процес неможна використовувати файл, тому що він буде використаний > by another processНу так і пробіжися по списках відкритих хендлів - глянь хто його тримає. Може дійсно залочений кимось?
Еразер, Rouse_ ні, я вже вийшов з того віку, щоб неперевірити насамперед, лочить хто вихідний файл. Тим більше, що попереднім рядком коду він копіювався зі сховища до робочої директорії.
але .. все ж таки вирішив перевірити ще раз, а раптом барабашки завелися.
Взагалі барабашки таки завелися.. не зовсім там, правда, де очікувалося.. Власне 18 години підходу було не з тією проблемою, проблема згадана була останньою краплею. Але за ті роки три його там різні фахівці з ГУІ та дизайну переробляли не раз, після всіх тих переробок знову повернувся до мене, бо як би не працює коректно під X64. Це передісторія. А історія в тому, що у мене після підміни користувач повідомляв, що система буде перевантажена і після натискання на ок що він з цим ознайомлений - перевантажувалася дезумовно.. Так ось, фахівці з інтерфейсу це відключили, а написали код з проханням тільки перевантажити систему. колись .. Причому останній дизайнер примудрився зробити помилку, внаслідок якої навіть це повідомлення не виводилося.
А виявляється, що якщо систему не перевантажити, то всі наступні операції з replaceRegKey були неуспішними (як описано вище), тому що replaceRegKey крім заміни робить і бакуп існуючої версії куща, в моєму випадку ім'я файлу для бакупа було завжди однакове (природно) різні для різних вуліїв). Так ось, до ребута системи бакуп файл від попередньої операції залочений системою (навіть якщо прибити сесію поточного користувача). Я не знаю, чи спостерігалося таке в чистому вин32, тому що в моїй початковій версії ребут робився завжди.ребут. Або хоча б про заборону соотв. котролів, які роблять підміну після першої операції підміни і до наступного ребута.
так що проблема в принципі знята, як майже завжди - виникнення спровоковане поєднанням будь-яких суб'єктивних факторів, у моєму випадку - вмілі фахівці з гуї, не ідеальна моя пам'ять на ньюанси древніх проектів, втома, інфо від тестерів, що проблема спостерігається тільки на X64 (хоча, можливо, аналогічна проблема після пошуків дизайнерів спостерігалася і рідною 32), етс.
перевантажувалася дезумовно -> перевантажувалась безумовно . вибачаюся також і за інші друкарські помилки - море у мене там їх :-(
2 evvcom, все правильно.. Але, на жаль, не завжди виходить правильно чинити.. Хоча в основному потім про це і шкодуєш. Типу - а їжачки всі кололися і кололися.