При установке WSH (см. файл WindowsXP-Windows2000-Script56-KB917344-x86-enu.exe в windows/downloads) если файлы уже присутствуют в system32 (например vbscript.dll) в виде ярлыков (возможно, битых ярлыков), они не перезаписываются с такой ошибкой при установке: err:setupapi:SetupDefaultQueueCallbackW copy error 5 L"C:\\windows\\temp\\IXP001.TMP\\vbscript.dll" -> L"C:\\windows\\system32\\vbscript.dll" Возможно ли это устранить?
Проблема знакомая: файл скорее всего read-only, поэтому wine не может его перезаписать. ещё со стороны wine не отличить обычный файл от ссылки. Пробовал снять атрибут read-only перед перезаписью, но не получилось. Возможно проблема с правами доступа. Надо подробней в этом разобраться
Проверил. Владелец ссылок root. При обращении к файлу wine просто переходит по ссылке. Поэтому права есть только для чтение! Как я уже говорил, внутри wine невозможно определить ссылка это или файл, поэтому и ссылкой внутри wine невозможно ничего сделать. Думаю, единственный выход здесь - убрать все ссылки
ещё надо проверить возможность удалять ссылку перед записью. Возможно это будет работать
Протестировал работу с ссылками: - При выполнении CreateFileA с атрибутом CREATE_ALWAYS файл перезаписывается, что логично - При удалении файла удаляется ссылка, а не файл, что тоже логично - Но! если удалять read-only файл, то удаление проваливается! (код 5 = ACCESS DENIED
DeleteFileW вызывает NtDeleteFile, а там содержится всего 2 строки: status = NtCreateFile( &hFile, GENERIC_READ | GENERIC_WRITE | DELETE, ObjectAttributes, &io, NULL, 0, FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, FILE_OPEN, FILE_DELETE_ON_CLOSE, NULL, 0 ); if (status == STATUS_SUCCESS) status = NtClose(hFile); Т.е при закрытии файла он должен удалиться. Но файл даже не открывается. Возвращаемый status = 0xc0000022
если убрать атрибуты GENERIC_READ | GENERIC_WRITE, и FILE_SHARE_READ | FILE_SHARE_WRITE, то файл без проблем удаляется. Проблема только в том, что в данном случае будут удаляться и read-only файлы, а этого быть не должно. можно попробовать использовать юниксовую функцию fstat для определения является ли файл ссылкой. Если является, то удалять его даже если он read-only
возникли проблемы с макросом S_ISLNK, который определяет является ли файл ссылкой. Написал тест под линукс. Там этот макрос работает прекрасно.
не знаю почему, но выражение (st.st_mode & S_IFLNK) всегда равно 32768 независимо от того файл это или ссылка. Кроме того st.st_mode тоже всегда равно 33060. Очень это странно
нашёл свою ошибку: если в пути используются символические, то необходимо применять lstat вместо stat Теперь символические ссылки удаляются независимо от прав на запись исходного файла.
Проверил исходное приложение: всё прекрасно устанавливается.
Решение добавляет функцию +/****************************************************************** + * NTDLL_IsFileALink + * check wheather file is a Unix link + * Fix eterbug #2469 + */ +BOOL NTDLL_IsFileALink( POBJECT_ATTRIBUTES attr )
