Ошибки, баги, вопросы - страница 2239

Новый комментарий
 
Stanislav Korotky:

Я тоже MSDN читаю. Поясните, это - майкрософт английского не знает, или они сами свою документацию не читают, или - последний вариант - флаги в MQL названы по аналогии WinApi но работают по-другому?

Взято вот отсюда - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ - Enables subsequent open operations on a file or device to request read access. Otherwise, other processes cannot open the file or device if they request read access.

FILE_SHARE_WRITE - Enables subsequent open operations on a file or device to request write access. Otherwise, other processes cannot open the file or device if they request write access.

Исходя из этого, первой программе достаточно указать флаг FILE_SHARE_READ для того чтобы вторая смогла читать. FILE_SHARE_WRITE требуется указать только в случае, когда известно, что помимо первой программы в файл будет писать и вторая.

Приведите пример в разнице поведения?


По приведённой ссылке, описание флагов не даёт представления о том, как правильно их использовать при попытке открыть один и тот же файл несколько раз.

Основываясь на данных из приведённого Вами описания, попробуйте ответить на вопрос, будут ли валиднымы четвёртый (hread_1) и пятый (hread_2) вызовы в примере ниже?

   HANDLE hwrite     =::CreateFile(L"test.txt", GENERIC_WRITE,FILE_SHARE_READ,                   nullptr,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_fail =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_READ,                   nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_ok   =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_1    =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_2    =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE|FILE_SHARE_READ,  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

Сразу скажу ответ: эти вызовы будут невалидными

 
Stanislav Korotky:

Я тоже MSDN читаю. Поясните, это - майкрософт английского не знает, или они сами свою документацию не читают, или - последний вариант - флаги в MQL названы по аналогии WinApi но работают по-другому?

Взято вот отсюда - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ - Enables subsequent open operations on a file or device to request read access. Otherwise, other processes cannot open the file or device if they request read access.

FILE_SHARE_WRITE - Enables subsequent open operations on a file or device to request write access. Otherwise, other processes cannot open the file or device if they request write access.

Исходя из этого, первой программе достаточно указать флаг FILE_SHARE_READ для того чтобы вторая смогла читать. FILE_SHARE_WRITE требуется указать только в случае, когда известно, что помимо первой программы в файл будет писать и вторая.

Чтобы не путаться в этих флагах, достаточно твёрдо уяснить, что открывая файл мы этими флагами разрешаем читать и\или писать другим процессам, а не себе.

 
Alexey Viktorov:

Чтобы не путаться в этих флагах, достаточно твёрдо уяснить, что открывая файл мы этими флагами разрешаем читать и\или писать другим процессам, а не себе.

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

 
Stanislav Korotky:

Я именно это и говорю, именно так понимаю документацию MS (в частности, тот, кто открывает файл на запись, может разрешить другим совместное чтение).

Может разрешить не только чтение, но и запись тоже. И если предполагается совместная запись, то в каждом должна быть разрешена совместная запись.

Stanislav Korotky:

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

А это ошибочно. Себе никогда ничего не разрешает и не поднимает себе никаких прав. Флаги FILE_SHARE_READ и FILE_SHARE_WRITE относятся к атрибутам открытого файла. Если в атрибутах нет разрешения от процесса которым файл уже занят, то и использовать этот файл не получится пока его не освободят.

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

 
Alexey Kozitsyn:

Вопрос к разработчикам.

Есть функция синхронизации:

С помощью нее иногда получаю такую ошибку:

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

Ошибка 4014 говорит о том, что:

Системная функция не разрешена для вызова

Как такое может быть?

А так, что она была сгенерирована каким-то другим вызовом.

Используйте ResetLastError() перед вызовом SymbolIsSynchronized

 
Slava:

А так, что она была сгенерирована каким-то другим вызовом.

Используйте ResetLastError() перед вызовом SymbolIsSynchronized

Да, уже сделал... Получается, что если в документации к функции явно не прописано, что в случае ошибки нужно вызывать GetLastError(), значит, что функция код ошибки не сбрасывает. Верно?

 
Slava:

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

 
A100:
В моем случае СервисДеск сейчас пишет что не может воспроизвести... соответственно требуется помощь зала... чуть позже я подробно распишу что и как 

Итак по заявке #1530548 СервисДеск не может воспроизвести ошибку https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 при том что у меня даже сейчас (в build 1881) устойчивое воспроизведение. Немного поразмыслив я понял почему! Ответ следующий: потому что у меня медленный компьютер (планшет)

Подобная ситуация была и в заявке #1952509 вот по этой проблеме https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

СервисДеск также первое время сообщал о том что не может воспроизвести ошибку. Мне стоило больших трудов убедить, что ошибка все-таки есть... в итоге:

Support Team 2018.02.10 22:35
 Похоже воспроизвели вашу проблему ещё в пятницу на слабой машине с 39 чартами.
Будем смотреть. Если потребуется запросим дополнительные данные. Спасибо.

В связи с этим возникает вопрос: А нужно ли вообще заморачиваться на такие ошибки? Или пусть себе тихо живут своей жизнью... авось не всплывут больше - ведь достаточно пересесть за быстрый компьютер?!

Эти вопросы возникают в контексте того что десяток другой чартов с несколькими экспертами\индикаторами вполне способны превратить быстрый компьютер в медленный (а среднестатистический трейдер использует именно много советников - вот пример https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 советника запущено)... или даже медленным он может стать на короткое время вследствии других обстоятельств (антивирус... другие программы... или сама система временно захватила почти все ресурсы).

И тогда наступит именно тот самый необъяснимый сбой 1 из 100 (ну и по законам природы естественно он возникает в самое неподходящее время)

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2016.08.03
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
A100:

Итак по заявке #1530548 СервисДеск не может воспроизвести ошибку https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 при том что у меня даже сейчас (в build 1881) устойчивое воспроизведение. Немного поразмыслив я понял почему! Ответ следующий: потому что у меня медленный компьютер (планшет)

Подобная ситуация была и в заявке #1952509 вот по этой проблеме https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

СервисДеск также первое время сообщал о том что не может воспроизвести ошибку. Мне стоило больших трудов убедить, что ошибка все-таки есть... в итоге:

Support Team 2018.02.10 22:35
 Похоже воспроизвели вашу проблему ещё в пятницу на слабой машине с 39 чартами.
Будем смотреть. Если потребуется запросим дополнительные данные. Спасибо.

В связи с этим возникает вопрос: А нужно ли вообще заморачиваться на такие ошибки? Или пусть себе тихо живут своей жизнью... авось не всплывут больше - ведь достаточно пересесть за быстрый компьютер?!

Эти вопросы возникают в контексте того что десяток другой чартов с несколькими экспертами\индикаторами вполне способны превратить быстрый компьютер в медленный (а среднестатистический трейдер использует именно много советников - вот пример https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 советника запущено)... или даже медленным он может стать на короткое время вследствии других обстоятельств (антивирус... другие программы... или сама система временно захватила почти все ресурсы).

И тогда наступит именно тот самый необъяснимый сбой 1 из 100 (ну и по законам природы естественно он возникает в самое неподходящее время)


у меня далеко не слабый комп. Но такая ошибка с открытием файла также возникает периодически. 

 
Vladislav Andruschenko:
 у меня далеко не слабый комп. Но такая ошибка с открытием файла также возникает периодически. 
Тем более что Вы не рядовой пользователь, а Вашими трудами пользуются многие и многие
1...223222332234223522362237223822392240224122422243224422452246...3519
Новый комментарий
Причина обращения: