Видимая нелогичность API ?

MouseTail · 28-05-10 10:31:50

Давайте попробуем рассмотреть нетрадиционную для холивара «винда-линь» тематику собственно написания ПО.

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

Возьмём простой пример, можно сказать, упрощённый. Писал я недавно кросплатформенный (win32 + win64 + winCE + GNU) класс для простой работы с файловым I/O. Ну там, открыть, закрыть, получить размер, прочитать блок, записать блок. В зависимости от дефайнов оно компилировалось с виндовым API или с libc. Для виндов вся релевантная документация аккуратно собрана в одном месте в MSDN Library. В линуксе же надо было вспомнить (потому что центрального портала по API нет и не предвидится), что функция называется fopen(), прочитать ман, обнаружить что она не подходит, потому что не возвращает дескриптор файла, посмотреть "See Also", найти open(), посмотреть у него "See Also" и перебором манов всех упомянутых функций найти нужные. Особенно озадачило название функции для получения размера файла -- stat(). Попутно выяснилось, что, например, когда fopen() возвращает указатель, fclose() его закрывает, а open() дескриптор, close() закрывает, следует ли ожидать, что функции на f работают без дескрипторов? Но нет. Функция stat() берёт имя файла, а fstat() - дескриптор. Нелогично! А ещё какой-то сумрачный гений додумался для 64-битных платформ делать отдельные прототипы и экспорты! Т.е. функция fstat() это не тоже самое, что функция fstat64(), не говоря уже о том, что libc, оказывается, не экспортирует ни тот ни другой символ! А экспортирует она __fxstat и __fxstat64, которые, разумеется, в манах не описаны вобще и их надо вызывать с другими параметрами, добавляя макрос версии либса.

Более того, как оказалось, в файловом API libc'а принципиально отсутствуют многие стандартные виндовые фишки. Например, флаги диспозиции типа OPEN_ALWAYS или TRUNCATE_EXISTING; также не совсем понятно как разграничить доступ к файлу из других контекстов — в виндах можно, например открыть файл с GENERIC_WRITE а разделить с FILE_SHARE_READ, а можно и наоборот (GENERIC_READ + FILE_SHARE_WRITE); так же там не оказалось overlapped IO и флагов оптимизации кэширования. В целом, неприятное впечатление осталось. Всё то, чем я привык пользоваться в виндах при написании программ, пришлось урезать и кастрировать, чтобы это можно было портировать под линукс.

Теперь вопрос, может я что-то пропустил и где-то в дебрях GNU есть какая-то секретная библиотека, которая всё это умеет?

Майор Очевидность · 28-05-10 15:07:19

умение искать — полезная вещь.

MouseTail · 28-05-10 15:14:38

Майор Очевидность пишет:

умение искать — полезная вещь.

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

ALEX · 28-05-10 15:36:16

Майор Очевидность пишет:

умение искать — полезная вещь.

Ты полностью оправдываешь свой ник. big_smile

Майор Очевидность · 28-05-10 15:46:55

MouseTail пишет:

о невозможности задать нужные режимы файлшаринга при открытии

ман по функции open присутствует во всех уважающих себя дистрибутивах.
приведу сетевой вариант.

MouseTail пишет:

о невозможности

и вообще. это даже уже не вопрос, а утверждение, чёрт возьми.
порождённое, по видимости, неумением читать.

MouseTail пишет:

об уродских именах экспорта

stdio.h, однако, рулит.

MouseTail пишет:

о логичности названий функций

слишком субъективно.
stat выдаёт не только размер, но и исчерпывающую статистику по файлу.

ont · 28-05-10 17:46:22

MouseTail пишет:

Более того, как оказалось, в файловом API libc'а принципиально отсутствуют многие стандартные виндовые фишки. Например, флаги диспозиции типа OPEN_ALWAYS или TRUNCATE_EXISTING

Вопиющая дезинформация ?! Могу ошибаться, но из источника linux.die.net/man/3/open:

OPEN_ALWAYS  --->   O_CREAT 
TRUNCATE_EXISTING --->  O_TRUNC

MOP3E · 28-05-10 17:47:53

Майор Очевидность пишет:

и вообще. это даже уже не вопрос, а утверждение, чёрт возьми.
порождённое, по видимости, неумением читать

Эмм, можешь привести здесь цитату из документации (можно на английском), опровергающую данное утверждение? Или, как всегда, сольёшся, придумав очередную туманную отмазку? Напомню: в данном случае вопрос стоит о назначении режимов доступа к файлам в линухе при помощи функций на С/С++.

Отредактировано MOP3E (28-05-10 17:48:29)

ont · 28-05-10 18:05:16

MouseTail пишет:

также не совсем понятно как разграничить доступ к файлу из других контекстов — в виндах можно, например открыть файл с GENERIC_WRITE а разделить с FILE_SHARE_READ, а можно и наоборот (GENERIC_READ + FILE_SHARE_WRITE);

Скорее всего, google меня любит ( тупо поискал linux FILE_SHARE_READ ):
www.linuxforums.org/forum/linux-program … linux.html
Откуда переходим к fcntl...

P.S. Вообще бы посоветовал купить книгу по основам программирования для linux. Сам, к примеру, читаю Майкл К. Джонсон, Эрик В. Троан. "Разработка приложений в среде Linux".
www.ozon.ru/context/detail/id/3261770/

Отредактировано ont (28-05-10 18:13:47)

MouseTail · 28-05-10 18:21:17

Майор Очевидность пишет:

ман по функции open присутствует во всех уважающих себя дистрибутивах. приведу сетевой вариант.

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

Майор Очевидность пишет:

и вообще. это даже уже не вопрос, а утверждение, чёрт возьми. порождённое, по видимости, неумением читать.

А давай ты, умеющий читать, расскажешь, с какими параметрами надо вызвать open(), чтобы получилось строго следующее:
CreateFile(FullPathName,GENERIC_READ,FILE_SHARE_WRITE,nil,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL or FILE_FLAG_NO_BUFFERING,0);

И заодно расскажи, как портировать под Линукс Overlapped I/O.

Майор Очевидность пишет:

stdio.h, однако, рулит.

C\C++, однако, не единственный язык программирования. И в данном конкретном случае (см. третий абзац заглавного поста) не подходит просто по отсутствию инструментария — нет таких компиляторов C\C++, которые из одного и того же исходника сгенерировали бы бинарник под вин32, вин64, винЦЕ и гну. Увы.

ont пишет:

Вопиющая дезинформация ?! Могу ошибаться, но из источника linux.die.net/man/3/open:
OPEN_ALWAYS ---> O_CREAT
TRUNCATE_EXISTING ---> O_TRUNC

А как быть с остальными диспозициями? CREATE_NEW, CREATE_ALWAYS, OPEN_EXISTING ? Я прекрасно знаю, что можно написать обвязку, которая проверяет наличие файла и что-то там делает в зависимости от этого. Но прелесть CreateFile() в том что это атомарная операция ФС. И никто другой не успеет создать файл между проверкой его на несуществование и пересозданием. А вот в линуксе - увы и ах.

Отредактировано MouseTail (28-05-10 18:31:26)

ont · 28-05-10 19:28:05

MouseTail пишет:

А как быть с остальными диспозициями? CREATE_NEW, CREATE_ALWAYS, OPEN_EXISTING ?

Ну давайте, попробую провести разминку для своих мозгов (если будет нужно, то можно и реальный код привести):

CREATE_NEW     --->  O_CREAT | O_EXCL   (если файл уже существовал, то будет ошибка)
CREATE_ALWAYS  --->  O_CREAT | O_TRUNC
OPEN_EXISTING  --->  тут просто не нужно добавлять опцию O_CREAT и, если файла нет, то будет ошибка.

Отредактировано ont (28-05-10 19:28:43)

Майор Очевидность · 28-05-10 19:31:02

MOP3E пишет:

Или, как всегда, сольёшся, придумав очередную туманную отмазку?

эмм... как всегда, да?
ну-с, ждём примеров моего "как всегда".

MouseTail пишет:

А как быть с остальными диспозициями? CREATE_NEW, CREATE_ALWAYS, OPEN_EXISTING ?

CREATE_NEW:

man пишет:

O_EXCL
If O_CREAT and O_EXCL are set, open() shall fail if the file exists.

CREATE_ALWAYS:

man пишет:

O_CREAT
If the file exists, this flag has no effect except as noted under O_EXCL below. Otherwise, the file shall be created;

OPEN_EXISTING:
просто ни один из этих флагов не должен быть задан.

MouseTail пишет:

А давай ты, умеющий читать, расскажешь, с какими параметрами надо вызвать open(), чтобы получилось строго следующее:
CreateFile(FullPathName,GENERIC_READ,FILE_SHARE_WRITE,nil,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL or FILE_FLAG_NO_BUFFERING,0);

FILE_SHARE_WRITE + FLAG_NO_BUFFERING: O_DSYNC
GENERIC_READ: O_RDONLY

далее пиши сам.
я не нанимался делать за тебя твою работу.
разве что ткнуть носом в несостоятельность твоих претензий. это всегда пожалуйста.

и, да, доказано: читать ты не умеешь.

ЗЫ:

MouseTail пишет:

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

дезинформация.

man пишет:

The check for the existence of the file and the creation of the file if it does not exist shall be atomic with respect to other threads executing open() naming the same filename in the same directory with O_EXCL and O_CREAT set.

MouseTail · 28-05-10 19:58:50

Ладно-ладно, уели lol lol
А про overlapped есть что-нибудь?

Майор Очевидность · 28-05-10 20:06:58

MouseTail пишет:

А про overlapped есть что-нибудь?

асинхронная приёмопередача инициируется параметром O_NONBLOCK.
опять же, читаем ман.

ont · 28-05-10 20:40:02

Майор Очевидность, 5+, только для CREATE_ALWAYS нужно было еще добавить O_TRUNC.
MouseTail, у меня глупый вопрос smile Для чего такой файл:

CreateFile(FullPathName,GENERIC_READ,FILE_SHARE_WRITE,nil,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL or FILE_FLAG_NO_BUFFERING,0);

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

Майор Очевидность · 28-05-10 20:43:20

ont пишет:

только для CREATE_ALWAYS нужно было еще добавить O_TRUNC.

да решил уж не править, поскольку Вы успели раньше smile

MouseTail · 28-05-10 21:11:21

ont пишет:

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

В оригинальном тексте там другие флаги, а этот пример - сферический в вакууме.
Язык Delphi, компилер FPC.

Форум StopLinux

Объявление

#1 28-05-10 10:31:50

Видимая нелогичность API ?

#2 28-05-10 15:07:19

Re: Видимая нелогичность API ?

#3 28-05-10 15:14:38

Re: Видимая нелогичность API ?

#4 28-05-10 15:36:16

Re: Видимая нелогичность API ?

#5 28-05-10 15:46:55

Re: Видимая нелогичность API ?

#6 28-05-10 17:46:22

Re: Видимая нелогичность API ?

#7 28-05-10 17:47:53

Re: Видимая нелогичность API ?

#8 28-05-10 18:05:16

Re: Видимая нелогичность API ?

#9 28-05-10 18:21:17

Re: Видимая нелогичность API ?

#10 28-05-10 19:28:05

Re: Видимая нелогичность API ?

#11 28-05-10 19:31:02

Re: Видимая нелогичность API ?

#12 28-05-10 19:58:50

Re: Видимая нелогичность API ?

#13 28-05-10 20:06:58

Re: Видимая нелогичность API ?

#14 28-05-10 20:40:02

Re: Видимая нелогичность API ?

#15 28-05-10 20:43:20

Re: Видимая нелогичность API ?

#16 28-05-10 21:11:21

Re: Видимая нелогичность API ?

Подвал форума