Подсистема Win32 на win64, RegRestoreKey
Искам малко странно .. Или по-скоро трябва да искам ..
Необходимо е да се изпълни тема за кошера, разбира се, разбирам, че това е малко странно, като се има предвид "виртуалността" на кошерите на 32-битовата подсистема на 64-битова платформа, но все пак. При изпълнение на темата получавам GetLastError = $00000020 - достъп до dynaid, всички права и привилегии от гледна точка на подсистемата win32 са зададени, потребителят има права на администратор и резервно копие на оператора, заявени са SE_RESTORE_NAME и SE_BACKUP_NAME и са получени успешно.
Благодаря за вниманието.
но отказаният достъп е код 5. Т.е. най-вероятно файлът, от който трябва да възстановите ключа, вече е отворен .. и или не е необходимо да се отваря изобщо, или се отваря със съответните ключове на ShareMode.
> Във файла WinError код 32 изглежда означава
да, съжалявам, правописна грешка, дадох грешно дешифриране, набързо, разбира се ERROR_SHARING_VIOLATION
Но. Тук ситуацията е малко по-различна. Файлът, разбира се, вече е отворен. Тъй като това са регистри :-). Но. Системата всъщност извършва замяната при рестартиране. Плюс това, същият код работи безупречно на "истинска" 32-битова система.
> но достъпът отказан е код 5.Още от дните на DOS. :-)
добре, до какво са стигнали. след 18 часа отстраняване на грешки на продукт, който не е съвсем естествен и не е възможно да се напише нещо подобно.. Код 0x20, syserrormessage казва „Процесът не може да получи достъп до файла, защото се използва от друг процес“. Във въпроса, с изключение на грешката „Достъп до Dyneid“, всичко останало е описано правилно ..
> Процесът няма достъп до файла, защото се използва > от друг процесЕ, прегледайте списъците с отворени дръжки - вижте кой го държи. Може би наистина е бил блокиран от някой?
Eraser, Rouse_ не, вече съм над тази възраст, за да не го правяпроверете първо кой заключва изходния файл. Освен това, с предишния ред код, той беше копиран от хранилището в работната директория.
но .. все пак реши да провери отново и изведнъж барабаните започнаха.
като цяло барабаните се задействаха .. не точно където, обаче, където се очакваше .. Всъщност 18 часа предварително отстраняване на грешки не беше със същия проблем, споменатият проблем беше последната капка.. Историята е следната - всъщност това беше първоначално моят код, функционален, написах го преди около три години .. Но през тези три години различни специалисти в GUI и дизайна го промениха там повече от веднъж, след всички тези промени, отново ми се върна, защото колкото и да работи правилно под X64. Това е предистория. И историята е, че след подмяната, потребителят е бил информиран, че системата ще бъде претоварена и след като е натиснал OK, че е запознат с нея, тя е била претоварена безусловно.. И така, специалистите по интерфейса са го изключили и са написали код с молба само за рестартиране на системата. преди известно време.. Освен това последният дизайнер успя да направи грешка, поради която дори това съобщение не беше показано.. :-(. Естествено, през тези няколко години всички тези нюанси бяха забравени..
Но се оказва, че ако системата не се рестартира, тогава всички последващи операции на replaceRegKey са били неуспешни (както е описано по-горе), поради причината, че replaceRegKey, в допълнение към заместването, прави и резервно копие на съществуващата версия на кошера, в моя случай името на файла за архивиране винаги е било едно и също (естествено различно за различните кошери). Така че, преди рестартиране на системата, архивният файл от предишната операция се заключва от системата (дори ако сесията на текущия потребител е убита). Не знам дали това се наблюдава в чист win32, тъй като в моята оригинална версия рестартирането винаги се извършваше .. Сега обяснявам на специалистите по интерфейса за необходимостта от безусловнорестартирайте. Или поне за забраната съгл. контролери, които правят замяна след първата операция за замяна и до следващото рестартиране.
така че проблемът е основно отстранен, както почти винаги - възникването е провокирано от комбинация от всякакви субективни фактори, в моя случай - квалифицирани GUI специалисти, паметта ми за нюансите на древните проекти не е перфектна, умора, информация от тестери, че проблемът се наблюдава само на X64 (въпреки че може би подобен проблем е наблюдаван след проучване на дизайнерите на родния 32) и т.н.
претоварен безусловно -> претоварен безусловно . Извинявам се и за други правописни грешки - имам много от тях :-(
2 evvcom, вярно.. Но, за съжаление, не винаги е възможно да постъпиш правилно.. Въпреки че най-често съжаляваш по-късно. Тип - и таралежите всички убодени и убодени.