в первый раз отказало в доступе, сразу повторил запуск, и всё прошло как по маслу.
Интересно, зря я в nul отправил сообщения takeown, icalcs: в таком варианте интересно было бы посмотреть на каком файле при первом проходе бэтч-файл споткнулся из сообщений этих утилит. Но вот у меня и еще у нескольких все чисто прошло за один запуск.
sysprg, Извините меня, не смог сделать .log, вы абсолютно правы - проблема в получении прав на доступ к конечной папке. Меня натолкнула мысль уважаемого V-Efremov'а - попробовать сделать это в ручном режиме. Я изменил права доступа к конечной папке "приоткрыл" ее и копирование прошло вручную. Затем не меняя прав доступа (приоткрытых) - выполнил ваш скрипт - копирование сработало. Сейчас верну права обратно. sfc /scannow - заработала.
Понятно, собственно назначение бэтч-файла в том и состояло, чтобы исключить ручные действия и у большинства, как я понял, проблем не было. Потому мне хотелось понять, почему же в некоторых случаях бэтч не срабатывал. Ладно, подожду до следующего подобного случая, если появится
После этого уже и бэтч-файл не нужен - файл уже скопирован. и sfc /scannow работает. Кстати, после выполнения бэтч-файла права на конечную папку остаются за администратором.
sysprg, Посмотрите еще на один скрин, обратите внимание на коменты между выполнением строк (я подтер частично, то что вы предлагали). Вроде как на конечном этапе копирования отказано.
Ну совсем не понимаю, и владение передано административной группе и права переданы текущему пользователю, а команда копирования не сработала. Но, я так понял, при втором проходе все в порядке? Если так, то значит мне нужно вставить временную задержку в этом бэтч-файле ПЕРЕД выполнением команды копирования. Возможно, у Вас СЛИШКОМ БЫСТРЫЙ процессор
Но, я так понял, при втором проходе все в порядке?
При втором и последующих не срабатывает. Атрибуты доступа к конечной папке под Админом не меняются в ходе запусков. Но достаточно открыть/установить атрибут "Изменение" для Администратора в этой конечной папке - ваш бэтч-файл прекрасно отрабатывает.
Атрибуты доступа к конечной папке под Админом не меняются в ходе запусков
Мне представляется, что сыграл роль добавленный Вами ключ /A в команде takeown: в моем оригинальном файле формат команды был "takeown /F %to% /R>nul" и без ключа /A владение директорией передавалось ТЕКУЩЕМУ пользователю, который должен был быть администратором. А добавление ключа /A осуществляет передачу владения не текущему пользователю, а АДМИНИСТРАТИВНОЙ ГРУППЕ, о чем сказано в сообщении на копии экрана, который Вы выложили. Дело в том, что последующая команда "icacls DirName netWanderer:F" предоставляет ПОЛНЫЙ доступ к директории DirName конкретно пользователю netWanderer. "netWanderer:F" означает, что пользователь netWanderer может делать с DirName все, что угодно вплоть до удаления, а открытие директории - минимальный уровень прав. То, что был опущен ключ /R в команде takeown, значения не имеет, поскольку в целевой директории не было поддиректорий. P.S: но в любом случае, этот бэтч-файл был ОДНОРАЗОВЫЙ и если сегодня придет новый билд, то больше он не понадобится никому, МS сборщики 14279 ЗЕВНУЛИ положить DLL в нужную директорию и больше это не повторится.
А кто нибудь шаманил с системой 32 bit? А то у меня нет такой папки C:\Windows\WinSxS\amd64........... Соответственно батник пишет, что не может найти файл из папки WinSxS
Должна быть аналогичная, скажем без префикса amd64. Должна быть x86 вместо amd64. Посмотрите под спойлером.
И еще: попробуйте выполнить УПРОЩЕННЫЙ файл
Код
@echo on cls setlocal set c1=C:\Windows\WinSxS\x86_microsoft-windows-servicingstack set c2=31bf3856ad364e35_10.0.14279.1000_none set from=%c1%-onecore_%c2%_5a92ee0dd788e433 set to=%c1%_%c2%_25a158fc7f85c69d
sysprg, Еще раз спасибо за ваш ответ под № #40 - для себя подчеркнул, кратко но информативно.
P.S. Только один человек спросил про 32-х разрядную систему. Заглянул в ваш спойлер в последнем ответе. У меня то же нет под рукой 32-х разрядки. Но по аналогу имеются 2 папки: В качестве источника - C:\Windows\WinSxS\x86_microsoft-windows-servicingstack-onecore_31bf3856ad364e35_10.0.14279.1000_none_fe74528a1f2b72fd В качестве назначения - C:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.14279.1000_none_c982bd78c7285567 Не знаю на сколько точно эти имена соответствуют в 32-х разрядной системе, но в принципе можно было бы подкорректировать ваш бэтч-файл в настройках set и кому-нибудь попробовать его запуск на 32-х разрядке.
Получилось. Система 32 bit/pro. За основу взял батник-патч от Drinko из сообщения 44. У меня он не заработал. Я покопался в папке WinSXS. Нашел нужные директории. Привожу строчки, которые я скорректировал под мою винду
set c1=%windir%\WinSxS\%PROCESSOR_ARCHITECTURE%_microsoft-windows-servicingstack set c2=31bf3856ad364e35_10.0.14279.1000_none set from=%c1%-onecore_%c2%_fe74528a1f2b72fd set to=%c1%_%c2%_c982bd78c7285567
Остальное в батнике без изменений. запуск с правами админа. Получилось со второго запуска. sfc /scannow работает.
В связи с введением в действие Постановления Правительства Российской Федерации от 14.11.2023 № 1905 т.н. "о запрете популяризации VPN" с 1 марта 2024 года - любое обсуждение способов обхода блокировок и VPN на портале запрещено!
Система 32 bit/pro. За основу взял батник-патч от Drinko из сообщения 44. У меня он не заработал. Я покопался в папке WinSXS. Нашел нужные директории. Привожу строчки, которые я скорректировал под мою винду