Баг RTL: файл открытый первым не закрывается под голым Wine

[Cheb]

Столкнулся с тем, что крашится TStrings.SaveToFile(), причём, только если файл существует, причём только если запускать командой
wine <путь к моему екзешнику>
а если запускать из файловых менеджеров - всё работает нормально. И при первом запуске когда файла нет - он спокойно создаётся.

Докопался до того, что создание файлового потока даёт Unable to open file, а Erase - Access Denied.

Причём! Если программа перезапускает себя, порождая второй процесс и убиваясь, то записать в файл, созданный первым процессом, удаётся успешно!

Вот я и думаю: "Что это было, Пух?"

[mig-31]

а что мешает скопилировать проект под Линух и не морочить голову с wine

[Sharfik]

а что мешает скопилировать проект под Линух и не морочить голову с wine

Кому есть дело до Линукса и издевательства над собой по адаптации, когда есть задачка интересная.
Саморазвитие- это вникать в суть проблемы, а не делать как все по шаблону написанному лентяем.

Столкнулся с тем, что крашится TStrings.SaveToFile(), причём, только если файл существует, причём только если запускать командой
wine <путь к моему екзешнику>
а если запускать из файловых менеджеров - всё работает нормально. И при первом запуске когда файла нет - он спокойно создаётся.

Докопался до того, что создание файлового потока даёт Unable to open file, а Erase - Access Denied.

Причём! Если программа перезапускает себя, порождая второй процесс и убиваясь, то записать в файл, созданный первым процессом, удаётся успешно!

Пути и параметры. Попробуй разведать как выглядит командная строка при запуске через менеджер. Там наверно либо как то форматируется путь, либо доп параметры приписываются.

[mig-31]

Кому есть дело до Линукса и издевательства над собой по адаптации, когда есть задачка интересная.

Использование wine не оправданно. И дело не в саморазвитии. Не вижу проблемы сделать линух версию:Лазарус и ФриПаскаль кроссплатфоменны.

[hinst]

надо проверить какие права на файл устанавливаются

Добавлено спустя 45 минут 49 секунд:
глюк скорее не странный а естественный для данной ситуации

[Дож]

надо проверить какие права на файл устанавливаются

Добавлено спустя 45 минут 49 секунд:
глюк скорее не странный а естественный для данной ситуации

А как тогда объяснить, что запущенный подпроцесс имеет доступ к файлу? Юзер, по идее, не должен меняться.

[Sharfik]

А как тогда объяснить, что запущенный подпроцесс имеет доступ к файлу? Юзер, по идее, не должен меняться.

а кстати он прав. Менеджер может запускаться с правами выше чем у запуска через wine. Место хранения файла попробуй сменить и протесть. Не знаю как это в Линуксе выглядит, но должно быть, в Винде опция такая есть "запуск программы с правами администратора".

[Дож]

Не знаю как это в Линуксе выглядит

setuid? :)

[Cheb]

надо проверить какие права на файл устанавливаются

664
owner: cheb
group: cheb

При том, что у папки права
777
owner: cheb
group: cheb

Смена прав файла на 777 не помогает.

P.S. глюк одинаковый на 32-битной древнеубунте и на 64-битной дебиан 7

Не вижу проблемы сделать линух версию:Лазарус и ФриПаскаль кроссплатфоменны.

На данном этапе родная линуксовая версия заморожена на неопределённый срок:
1. я делал приложение 32-битным, там слишком много бинарной шаманистики чтобы это портировать на 64 бита без значительных затрат времени. Которого сейчас не хватает. Линуксовое приложение обязано быть 64 битным (стандарт сейчас), а вайн нормально выполняет 32-битные на 64-битной линуксятине.
2. с тех пор, как приостановил линуксовую версию, я добавил поддержку геймпада xbox 360, снижения качества рендера в зависимости от заряда батареи ноутбука и прочие плюшки. Чтобы повторить это в линуксовой версии, там надо полностью переделывать на GTK+ (сейчас на голых обращениях к X серверу). Это много времени, которого сейчас не хватает.
3. Я рассматриваю вайн как один из наиболее стабильных и надёжных API линукса, где не надо бросаться переписывать всю программу каждые два года от того, что разработчикам графических оболочек попала очередная вожжа под хвост.
4. С учётом всего вышеперечисленного, на данном этапе поддержка родной линуксовой версии неоправдана по трудозатратам.

Как временную затычку, добавил на старте проверку возможности записи в существующий файл (раньше записываемость папки проверялась тупо созданием и удалением временного файла). Так что оно теперь вежливо говорит, что нет прав на папку и вываливается.

[Vapaamies]

Я рассматриваю вайн как один из наиболее стабильных и надёжных API линукса, где не надо бросаться переписывать всю программу каждые два года от того, что разработчикам графических оболочек попала очередная вожжа под хвост.

Это сразу можно в рамочку -- и на стенку.

С учётом всего вышеперечисленного, на данном этапе поддержка родной линуксовой версии неоправдана по трудозатратам.

Ровно то же отвечает Embarcadero на презентациях новых версий Delphi, когда у них спрашивают о планах поддержки Linux.

[alexs]

Бред.
Ищите ошибку в своём коде.
Правильно написанное работает и в винде и в вайне.
А вообще - компилируйте нативно под каждую платформу. Не изобретайте себе геморрой.

[mig-31]

А вообще - компилируйте нативно под каждую платформу. Не изобретайте себе геморрой.

Полностью поддерживаю.

3. Я рассматриваю вайн как один из наиболее стабильных и надёжных API линукса, где не надо бросаться переписывать всю программу каждые два года от того, что разработчикам графических оболочек попала очередная вожжа под хвост.

Это в корне не правильный подход. Потому что вине сам по себе нестабилен. Это видно и по отчетам работоспособности виндовс программ под ним. Вине не являеться в прямом смысле линух API, а переводчиком виндовс API на линух API.

Что касаеться линуховых графических библиотек, так поддержка устаревших GTK2 и QT3 присутствует в самых новых версиях линух дистрибуций.
Если вам нужна длительная поддержка с минимальными изменениями так смотрите в сторону Ред Хэт (13 лет официальной поддержки, при определенной подписке до 20 ) и его клонов CentOS, Scientific Linux или SuseEnterprise.

[Cheb]

Бред.
Ищите ошибку в своём коде.

Собирался сказать, что всё совершенно не так, и даже воздуху набрал для гневной отповеди... Как вдруг начали отваливаться функции типа Trim() или Utf8Encode()!
И тогда Чеб подумал: это "жу-жу-жу" неспроста! И включил -Co -Cr
Программа упала, не успев даже подняться. Лезу в код, и... Ох, мать моя женщина И сколько там ещё таких перлов?
SetLength(ModuleCiMs, 1); ModuleCiMs[1]:= nil;
[epic facepalm]
Уползаю посыпать голову пеплом.

[Cheb]

Заодно обнаружил, что WTOpen(), когда графический планшет не подключен, вместо того, чтобы вернуть 0, возвращала Ок, но номер устройства ставила $ffffffff. И дальше у меня с ней шёл обмен шумом океанов Марса (интересно, может поэтому в вайне при отсутствии планшета получались такие конские значения его разрешения и чувствительности пера?)

А какую западлу GetTickCount() подложила! Это к слову: если тик хранить как longint, а ноутбук не перезагружать примерно месяц - 31 бит переполняются и программа начинает делать хряп (ибо GetTickCount() возвращает dword)

[Mirage]

И включил -Co -Cr

Ну range checks вещь крайне полезная, достаточно, чтобы во время разработки её держать включенной. Да и вообще дебажный режим.

А с GetTickCount() это старая известная проблема.