Здравствуйте, grosborn, Вы писали:

G>Вообще-то есть такая штука как блокировки. Я понимаю, что простые решения некошерны по МС, но все же.

Если речь про LockFile(Ex), то это не поможет, если файлов два и больше, и требуется
перезаписать их в рамках единой транзакции.

Здравствуйте, okman, Вы писали:

O>Это да, но остается еще одна проблема — сериализация доступа.
O>Например, когда два или больше пользователей одновременно перезаписывают один и
O>тот же файл внутри All Users, после чего его состояние становится неконсистентным.
O>Хотя это все тоже решается всякими мьютексами/семафорами. Правда, для этого
O>они должны быть снабжены префиксом Global, и чтобы их могли открывать пользователи с
O>разными правами, все равно придется звать SetSecurityInfo на этих объектах

Эй, ребята, а вам не кажется, что коли речь заходит о многопользователях, консистентности и транзакциях, то стоит уже взять нормальную настоящую СУБД? Заодно не будет проблем, если завтра All Users уедет на сетевую шару в домене.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Khimik.

O>Грубо говоря, Вам нужно подключить ко всем исполняемым файлам специальные манифесты.
O>Манифест — это просто текстовый ресурс в формате XML, который, кстати, может лежать
O>рядом с исполняемым файлом. Его содержимое может быть примерно таким:
O>

O><?xml version="1.0" encoding="utf-8" standalone="yes"?>

O><assembly
O>    xmlns="urn:schemas-microsoft-com:asm.v1"
O>    manifestVersion="1.0">

O>    <assemblyIdentity
O>        type="win32"
O>        name="Company.Product.Module"
O>        version="1.0.0.0"
O>        processorArchitecture="x86">
O>    </assemblyIdentity>

O>    <description>My Cool Module</description>

O>    <dependency>
O>        <dependentAssembly>
O>            ...
O>        </dependentAssembly>
O>    </dependency>

O>    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
O>        <security>
O>            <requestedPrivileges>
O>                <requestedExecutionLevel
O>                    level="asInvoker"
O>                    uiAccess="false"/>
O>            </requestedPrivileges>
O>        </security>
O>    </trustInfo>

O>    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
O>        <application>
O>            <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
O>            <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
O>        </application>
O>    </compatibility>

O>    <application xmlns="urn:schemas-microsoft-com:asm.v3">
O>        <windowsSettings>
O>            <dpiAware
O>                xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
O>        </windowsSettings>
O>    </application>

O></assembly>
O>

O><assemblyIdentity> нужен для идентификации исполняемого файла или динамической библиотеки.
O>Это обычная метаинформация, но иногда она может играть важную роль при выборе
O>нужной версии сборки.

O><description> опционален.

O>В <dependency> прописываются зависимости от различных общих и частных сборок,,
O>установленных на компьютере, от конкретных их версий (это один из механизмов разруливания
O>проблемы "Dll Hell"). Типичный пример — зависимость от библиотеки Common-Controls шестой версии.

O><trustInfo> определяет, какие уровень прав требуется для корректной работы приложения.
O>Варианты: asInvoker — запуск с правами пользователя, highestAvailable — максимально возможный
O>уровень (пользователю будет показано окно с предложением ввести имя пользователя и пароль),
O>requireAdministrator — приложению требуются администраторские права (снова будет запрос UAC).
O>Подсказка: highestAvailable и requireAdministrator большинству нормальных приложений почти
O>никогда не нужны.

O><compatibility> нужен приложениям на Windows 7 и выше, которые хотят "включить" все заплатки,
O>выпущенные после выхода Vista, и работать напрямую, без "эмуляции" поведения Vista.
O>Например, есть известный глюк в GetOverlappedResult, который починили только в Windows 7,
O>однако для совместимости оставили возможность сохранить старое поведение этой функции.

O><dpiAware> показывает, что приложение будет правильно отображаться на настройках с высоким DPI.
O>Без этой опции все GUI-шные элементы на таких настройках будут просто и тупо растянуты.

O>Такой файл манифеста нужно сохранить (в UTF-8) и включить в exe как ресурс.
O>Тип ресурса — 24, ID — 1 (для dll ID равен 2). Либо можно положить данный файл прямо рядышком с
O>exe-файлом, присвоив ему соответствующее имя. Например, для myprogram.exe манифест должен
O>называться myprogram.exe.manifest.

O>После описанных манипуляций загрузчик Windows будет воспринимать данный exe как полностью
O>совместимый с Vista/Windows 7 и никакая виртуализация задействована не будет.
O>Это, разумеется, потребует полного отказа от запись в системные папки и разделы реестра, а
O>также соблюдения всех остальных, документированных в MSDN, "норм поведения".
Во! Гутное разъяснение!
А где вообще подробнее почитать про эти манифесты? Что куда, зачем и сколько? А то были совершенно другого плана странные проблемы в Висте\7 (в основном аккурат проблемы про CommonControls), и приходится медитировать методом тыка. А хотелось бы ясности хоть какой-то... Какие XML-теги на что влияют и.т.д.

Здравствуйте, okman, Вы писали:

O>Если речь про LockFile(Ex), то это не поможет, если файлов два и больше, и требуется
O>перезаписать их в рамках единой транзакции.

Тогда делаете, как было сделано в том же Paradox: один файл для блокировок. Его и пытаетесь захватить. Захватили — меняем все остальные (их лочить не нужно). Ну и FILE_SHARE_READ не забываем. Или FILE_SHARE_DENY (или как там?).

P.S. Прав был Спольски. Без знания основ нефиг начинать формочки клепать.

> G>Вообще-то есть такая штука как блокировки. Я понимаю, что простые решения некошерны по МС, но все же.
>
> Если речь про LockFile(Ex), то это не поможет, если файлов два и больше, и требуется
> перезаписать их в рамках единой транзакции.

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

И вообще, ТС не дал достаточно информации, что бы что-то ему корректно подсказать.

> Эй, ребята, а вам не кажется, что коли речь заходит о многопользователях, консистентности и транзакциях, то стоит уже взять нормальную настоящую СУБД? Заодно не будет проблем, если завтра All Users уедет на сетевую шару в домене.

И поднимать сервер? Если бы он подробнее написал чего хочет.

Здравствуйте, Carc, Вы писали:

C>А где вообще подробнее почитать про эти манифесты? Что куда, зачем и сколько? А то были совершенно другого плана странные проблемы в Висте\7 (в основном аккурат проблемы про CommonControls), и приходится медитировать методом тыка. А хотелось бы ясности хоть какой-то... Какие XML-теги на что влияют и.т.д.

Практически вся информация, на удивление, лежит здесь — http://msdn.microsoft.com/en-us/library/windows/desktop/aa375365(v=vs.85).aspx и здесь — http://msdn.microsoft.com/en-us/library/windows/desktop/aa375190(v=vs.85).aspx
Для unmanaged-вещей в основном нужны сведения только по Application Manifests и Assembly Manifests.
Про High DPI там же, неподалеку — http://msdn.microsoft.com/library/dd464646.aspx
Вот информация про элемент <compatibility> — http://msdn.microsoft.com/en-us/library/dd371711(v=vs.85).aspx
И в сети еще ходит PDF под названием v7dev.pdf — "Обеспечение совместимости приложений в Windows Vista и
Windows 7", рекомендую найти и прочесть.

Здравствуйте, grosborn, Вы писали:

G>Вообще-то для единой транзакции по нескольким файловым операциям совсем не нужно создавать сервер транзакций, не говоря уже о том что зачастую транзакция не нужна или можно обойтись другими алгоритмами.

Да если уже на то пошло, для обсуждаемой задачи (сериализация доступа к файлу) не нужны ни базы
данных (ну разве что какая-нибудь SQLite), ни серверы транзакций. Вполне сойдет и LockFileEx.
Просто те же Win32-мьютексы дают чуть больше возможностей. Например, если один из пишущих
процессов свалится где-нибудь посреди перезаписи, этот факт легко отследить — WaitForSingleObject
вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.

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

Не угадал — большую часть времени я работаю в одиночку.
А на счет простых и логичных вещей — спасибо, принял к сведению.

> вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.

Не работает при сбоях.
Давно уже отработан простой и надежный транзакционный подход с использованием локов или чуть сложнее в целях производительности с журналированием. Только вот ввиду доведения до ума всяких sqlite и sql ce уже редко применяется, производительность не на первом месте. ТС может быть проще поднять сервис с БД и не мучиться. Несколько элегантных кликов мышой и оно работает прямо из коробки.

Здравствуйте, grosborn, Вы писали:

>> вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.

G>Не работает при сбоях.

Заинтригован до мозга костей. А можно чуток подробнее ?

>>> вернет STATUS_ABANDONED и читатель будет знать, что данные трогать нельзя, т.к. они порушены.
>
> G>Не работает при сбоях.
>
> Заинтригован до мозга костей. А можно чуток подробнее ?

Не сохраняется между сеансами работы компьютера.
Если у тебя есть такое состояние базы данных/файла как "данные неконсистентны", то получение признака должно быть надежным. То есть признак этого состояния должен записываться на диск. Поэтому в современных БД с целью производительности наличия такого состояния избегают.

Здравствуйте, grosborn, Вы писали:

G>Не сохраняется между сеансами работы компьютера.

Нужный механизм не очень-то сложно прикрутить.

Например:

1. Захватываем глобальный мьютекс.
2. Делаем бэкап файлов, подлежащих перезаписи.
3. Устанавливаем где-нибудь в реестре или в отдельном файле специальный бит.
Это значит, что операция началась. Бит нужно сразу сбросить на диск (FlushFileBuffers/
RegFlushKey).
4. Спокойно перезаписываем файлы.
5. Сбрасываем бит.
6. Освобождаем мьютекс.

Системный сбой на стадиях 1-3 или 5-6 не страшен, так как файлы либо ЕЩЕ не перезаписаны,
либо УЖЕ перезаписаны. Сбой на стадии 4 тоже не опасен, так как при следующем запуске
приложения оно будет знать, что следует читать файлы из резервного хранилища, так как
бит операции не был сброшен.

Нет, все не то. Сложно, некрасиво, неуниверсально, ненадежно. Локи чем хороши, тем что решение отлажено можно сказать поколениями. И методом ошибок и пинков, с локами научили работать большинство программистов корректно. Хотя еще встречаются иногда в линуксах или виртуалках с ними проблемы, но это на уровне признанных багов. А так они работают корректно почти везде.
Твой подход, к примеру, не будет работать если будет доступ к общим данным по сети.

Здравствуйте, grosborn, Вы писали:

G>Нет, все не то. Сложно, некрасиво, неуниверсально, ненадежно.

На счет "сложно" и "некрасиво" — можно опустить.
По поводу "неуниверсально" и особенно "ненадежно" — пожалуйста, аргументы в студию.

G>Твой подход, к примеру, не будет работать если будет доступ к общим данным по сети.

Два компьютера в сети, на обоих запущена программа, использующая общий файл настроек из
сетевой шары ? Извини, но я тогда тоже могу придумать еще более извращенный сценарий.
Например, у пользователя "полетел" файловый антивирус и запорол половину файловой системы.
И ничего тут не сделаешь, ни блокировками, ни мьютексами, ни СУБД с журналированием.
Спасет только бэкап файлов по расписанию, раз в минуту, на удаленный хостинг.

> Два компьютера в сети, на обоих запущена программа, использующая общий файл настроек из
> сетевой шары ? Извини, но я тогда тоже могу придумать еще более извращенный сценарий.

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

Здравствуйте, MikePetrichenko, Вы писали:

D>>я в свое время чуть мозгами не двинулся пытаясь понять что за голимые эффекты Потом уже въехал как это все делается.

MP>Читаем правила поведения программ под Windows (Windows Application Design Guide). Там черным по-английски (а есть и книга написанная черным по-русски, от MS Press) прописано, что, где и как хранить.
Маленкая поправочка: я на эти голимые эффекты наткунулся и питался въехать когда тока-тока бета Висты вышла.
Уже потом и букварь почитал и у умныхлюдей спросил.

MP>По поводу "AllUsers не папка". Курить SHGetSpecialFolderLocation и аналогичное. Там же есть ID системных папок, в том числе и AllUsers.
Да SHGetSpecialFolderLocation выдает AllUsers. И туда можно зайти и там что-то написать. Но (сюрприз) это токлько ссылка на ProgramData. То что мы напишем в AllUsers автоматом появляется ProgramData и наоборот. В FAR-е это хорошо видно что это не папка, а ссылка. В проводнике ProgramData вообще скрыта по умолчанию.
Ссылка сделана скорее всего для совмесимости с пред. версиями Винды.

D>>Так что лучше делать все как положено и не заниматься изобретением велосипеда
MP>Вот это поддерживаю! Это архиправильно!

Здравствуйте, drpops, Вы писали:

D>Маленкая поправочка: я на эти голимые эффекты наткунулся и питался въехать когда тока-тока бета Висты вышла.
D>Уже потом и букварь почитал и у умныхлюдей спросил.

Эти рекомендации (букварь) были еще со времен Win 95. И там точно расписано: что, где, как и когда хранить. Куда DLL запихивать, для чего Common Files нужна и много, много другой интересной информации. Читали бы, не нужно было бы "въезжать" на Vista.

D>Да SHGetSpecialFolderLocation выдает AllUsers. И туда можно зайти и там что-то написать. Но (сюрприз) это токлько ссылка на ProgramData. То что мы напишем в AllUsers автоматом появляется ProgramData и наоборот. В FAR-е это хорошо видно что это не папка, а ссылка. В проводнике ProgramData вообще скрыта по умолчанию.
D>Ссылка сделана скорее всего для совмесимости с пред. версиями Винды.

Для приложения это абсолютно не важно. Сегодня — ProgramDara, завтра — ключ в реестре, послезавтра — так всеми любимое облачное хранилище. Для этого (чтобы приложению было фиолетово и оно работало везде) и есть SHGetSpecialFolderPath и прочее. Т. е. по ID Special Folder получаете путь к ней и работаете. Кстати, в Win 7 не только AllUsers ссылка — там их куча. А если задача стоит сделать результат работы (файл) видимым пользователю — пишем Shared Documents (Общие документы). Если что — это тоже ссылка, но она видна в проводнике.

Здравствуйте, grosborn, Вы писали:

G>Ну здрасте. Ни разу не запускал программы с сетевой шары? Только корректно проинсталлированные? Если мы работаем с общим файлом, нельзя закладываться на то, что он будет строго в определенном месте на диске.

Похоже, пора мне переходить от защиты к нападению.

Во-первых, речь шла о файле с общими данными, расположенном в глубинах Users\Public или ProgramData.
Расшаривать содержимое папки ProgramData немного странновато, тебе не кажется ?
Ну даже если так, если мы храним общий файл данных на шаре, чем здесь блокировки (LockFileEx)
помогут в плане обеспечения атомарности и консистентности ?

Смотри — есть программа, которая использует файл settings.ini, расположенный на сетевой шаре.
И в один момент на разных компьютерах запущено несколько экземпляров данной программы, причем все они
юзают settings.ini, то на чтение, то на запись. Допустим, одна из копий программы лочит файл, затем
начинает наполнять его новым содержимым. Вдруг, по какой-то внешней причине, доступ в сеть компьютера,
который пишет в файл, неожиданно обрывается. Начало файла наполнено новыми данными, конец — старыми.
Насколько я помню, когда залочивший файл процесс отваливается, ОС сама разлочивает его и делает
доступным другим процессам. Все, получаем неконсистентные данные. При этом то, что файл лежит где-то
на шаре, не имеет в данном примере никакого значения — процесс просто может неожиданно завершиться
из-за ошибки (например, в другом потоке), и состояние файла останется противоречивым.
И новый процесс, который ждет своей очереди на чтение settings.ini, никак не будет уведомлен о
том, что произошла критическая ошибка. Я не понимаю, хоть убей, чем и как здесь помогут блокировки ?

Далее. Ты пишешь, что решение с мьютексами неуниверсально.
Возражаю. Его можно использовать не только с файлами, но и с реестром, да хоть слать данные
куда-нибудь по HTTP, а сам алгоритм останется неизменным — захват мьютекса, бэкап, установка
флага, перезапись, сброс флага, освобождение мьютекса. Лочить же можно только файлы.

По поводу сложности.
Для тривиальных случаев решение, использующее легкие обертки над Win32 API, укладывается в
несколько десятков строк кода. С "фишками" — в пару сотен строк. При этом код практически
линейный, без ветвлений, в один поток. Ну и что здесь сложного ? Это, по сути, день работы +
день тестирования. Ну еще, может быть, потребуется локализовать некоторые сообщения об ошибках,
но это уже к теме сильного отношения не имеет.

Аргументов по поводу ненадежности (шара не в счет, поскольку LockFileEx тоже не лучше, если
только ты не докажешь обратное) и неуниверсальности я пока не увидел.

Поэтому не нужно писать про фрагментарность знаний, про "извращенное MC мышление" и т.д.
Хотя в этом есть доля истины, потому что я стараюсь хватать знания жадно, а не ждать,
пока они ко мне сами придут.

И еще. У тебя какая-то язвительная манера вести разговор. Складывается впечатление, что
ты задолго до разгорания спора пытаешься от чего-то отбиваться или что-то доказывать — не знаю.
Лично у меня нет желания вступать в какие-то "прения" и я уважаю тебя хотя бы как собеседника.
Если я в чем-то неправ и мне это доказывают (аргументированно!), я легко признаю свою неправоту.
И готов буду признать и в этот раз, если аргументы последуют.

Здравствуйте, MikePetrichenko, Вы писали:

MP>Здравствуйте, drpops, Вы писали:

D>>Маленкая поправочка: я на эти голимые эффекты наткунулся и питался въехать когда тока-тока бета Висты вышла.
D>>Уже потом и букварь почитал и у умныхлюдей спросил.

MP>Эти рекомендации (букварь) были еще со времен Win 95. И там точно расписано: что, где, как и когда хранить. Куда DLL запихивать, для чего Common Files нужна и много, много другой интересной информации. Читали бы, не нужно было бы "въезжать" на Vista.
Угу, угу. А еще со времен вин95 были рекомендации класть все ДЛЛ в %SYSTEM%, а мы не читали этих рекомендаций и теперь не приходится въезжать что такое Dll Hell...
Это к вопросу рекомендаций от MS. Они много чего рекомендуют, но порекомендовать дело 2-ух минут, а переписывать приложение занятие совершенно другого времени.

D>>Да SHGetSpecialFolderLocation выдает AllUsers. И туда можно зайти и там что-то написать. Но (сюрприз) это токлько ссылка на ProgramData. То что мы напишем в AllUsers автоматом появляется ProgramData и наоборот. В FAR-е это хорошо видно что это не папка, а ссылка. В проводнике ProgramData вообще скрыта по умолчанию.
D>>Ссылка сделана скорее всего для совмесимости с пред. версиями Винды.

MP>Для приложения это абсолютно не важно. Сегодня — ProgramDara, завтра — ключ в реестре, послезавтра — так всеми любимое облачное хранилище. Для этого (чтобы приложению было фиолетово и оно работало везде) и есть SHGetSpecialFolderPath и прочее. Т. е. по ID Special Folder получаете путь к ней и работаете. Кстати, в Win 7 не только AllUsers ссылка — там их куча. А если задача стоит сделать результат работы (файл) видимым пользователю — пишем Shared Documents (Общие документы). Если что — это тоже ссылка, но она видна в проводнике.
Слушайте, братцы. А вот если портабельная версия, что тогда? Если софтина с флешки работает? И ей попросту необходимо держать какие-либо данные где-то рядом с собой. Тогда как? Как эти все ховенные SHGetSpecialFolder помогут!?!
Понимаю, что в ветке несколько другая ситуация обсуждается и вариант с портабельностью скорее всего просто не в ту степь. Но все же!?! (просто у меня схожая ситуация, и как-то обсуждали где-хранить рабочие материльцы\настройки\и_прочия)

Здравствуйте, Carc, Вы писали:

C>Угу, угу. А еще со времен вин95 были рекомендации класть все ДЛЛ в %SYSTEM%, а мы не читали этих рекомендаций и теперь не приходится въезжать что такое Dll Hell...
C>Это к вопросу рекомендаций от MS. Они много чего рекомендуют, но порекомендовать дело 2-ух минут, а переписывать приложение занятие совершенно другого времени.

Вот и зря. Общие для всех приложений одной конторы DLL должны лежать в Common Files. И если бы так все поступали, то не было бы DLL Hell. А в System клались только системные DLL. Причем — глобальносистемные. А то есть любители перетирать новые версии старьем. Потом из-за таких вот "не читал, но осуждаю" и проблемы. Так что настоятельно рекомендую таки почитать. Не считайте себя умнее разработчиков ОС.

C>Слушайте, братцы. А вот если портабельная версия, что тогда? Если софтина с флешки работает? И ей попросту необходимо держать какие-либо данные где-то рядом с собой. Тогда как? Как эти все ховенные SHGetSpecialFolder помогут!?!
C>Понимаю, что в ветке несколько другая ситуация обсуждается и вариант с портабельностью скорее всего просто не в ту степь. Но все же!?! (просто у меня схожая ситуация, и как-то обсуждали где-хранить рабочие материльцы\настройки\и_прочия)

Ну так на флешке нет ограничений, таких как на ProgramFiles. Там уж сам куда угодно клади. И DLLки свои с собой таскай.

P.S. Кстати, вот, Borland тоже не читал те самые рекомендации. Имеет теперь анонизм с D6-D7, которая проекты в ProgramFiles хранит и компилит (по-умолчанию, а вот пакеты из иного места она в принципе не видит).