错误、漏洞、问题 - 页 2239

[Ilyas]

Stanislav Korotky:

我也读MSDN。解释一下，是微软不懂英语，还是他们自己不看他们的文档，还是最后一种选择--MQL中的标志的命名与WinApi类似，但工作方式不同？

摘自这里 - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -启用对一个文件或设备的后续打开操作，请求读取访问。否则，其他进程如果请求读取访问，就不能打开该文件或设备。

FILE_SHARE_WRITE -启用对一个文件或设备的后续打开操作，以请求写访问。否则，其他进程如果请求写访问，就不能打开该文件或设备。

因此，第一个程序只需要设置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);

我马上告诉你答案：这些电话将是无效的

[Alexey Viktorov]

Stanislav Korotky:

我也读MSDN。解释一下，是微软不懂英语，还是他们自己不看他们的文档，还是最后一种选择--MQL中的标志的命名与WinApi类似，但工作方式不同？

摘自这里 - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -启用对一个文件或设备的后续打开操作，请求读取访问。否则，其他进程如果请求读取访问，就不能打开该文件或设备。

FILE_SHARE_WRITE -启用对一个文件或设备的后续打开操作，以请求写访问。否则，其他进程如果请求写访问，就不能打开该文件或设备。

因此，第一个程序只需要设置FILE_SHARE_READ，第二个程序就可以读取。FILE_SHARE_WRITE只有在你知道第二个程序也会写到该文件时才可以使用。

为了避免这些标志的混淆，只要确保当我们打开一个文件时， 这些标志允许其他进程读取和/或写入，而不是我们自己。

[Stanislav Korotky]

Alexey Viktorov:

为了避免对这些标志的混淆，只需坚定地理解，当我们打开一个文件时， 这些标志允许其他进程读取和/或写入，而不是我们自己。

这正是我所说的，这正是我对MS文档的理解（特别是，打开文件进行写作的人可以允许其他人分享阅读）。推荐的标记技术则相反--第二个进程使用写共享标记来授权阅读被写入的文件（也就是说，它有点绕过第一个进程来授权阅读，尽管第一个进程没有实现写共享权限）。这听起来甚至是不自然的。总之，我去读解释了。

[Alexey Viktorov]

Stanislav Korotky:

这正是我要说的，这就是我对MS文档的理解（特别是，谁打开一个文件进行写作，就可以让其他人一起阅读）。

不仅可以允许阅读，也可以允许写作。如果有任何共享写入，每个进程都应该有共享写入权限。

斯坦尼斯拉夫-科罗茨基。

为解决这个问题而推荐的使用标志的方法假定了相反的情况--第二个进程使用写入标志来授权自己读取正在写入的文件（即它通过提高授权 来绕过第一个进程，即使第一个进程没有授予对共享文件的写入权限）。这听起来甚至是不自然的。总之，我去读解释了。

而这是错误的。自我从不允许任何东西或向自己提出任何权利。FILE_SHARE_READ和FILE_SHARE_WRITE 标志是指一个开放文件的属性。如果这些属性不包括已经使用该文件的进程的许可，则该文件不能被使用，直到它被释放。

这就是那些例子中的工作方式。第一个打开的文件是用来写的，允许其他进程读取，而第二个当你打开它时，试图禁止（不允许）写给已经在使用该文件的人。这里是它变得无奈的地方......这就像，谁先站起来，谁就走开......。

[Slava]

Alexey Kozitsyn:

给开发者的问题。

有一个同步功能。

我有时会遇到这样的错误。

例如，该指标在USDJPY上运行，而我在EURGBP符号上得到一个错误。同时，在终端有一个开放的 欧元兑英镑图表。

错误4014说。

系统函数不允许被调用

怎么可能呢？

有可能是由其他调用产生的。

在调用SymbolIsSynchronised之前使用ResetLastError()。

[[删除]]

Slava:

因此，它是由其他一些调用产生的。

在调用SymbolIsSynchronized之前使用ResetLastError()。

是的，我已经做了...事实证明，如果在函数文档中没有明确写明在出错时必须调用GetLastError()，就意味着该函数没有重置错误代码。对吗？

[[删除]]

Slava:

另外，我想知道哪些功能有可能导致指标中出现这个错误？

[A100]

A100:
在我的案例中，ServiceDesk现在写道，它不能播放...因此，需要房间的帮助......稍后我将详细描述什么和怎么做。

因此，在第1530548号 请求中，ServiceDesk无法重现错误https://www.mql5.com/ru/forum/1111/page1628#comment_2702870，即使我现在有稳定的播放（在构建1881）。经过一番思考，我想明白了原因!答案是：因为我有一台慢速的电脑（平板电脑）。

我在第1952509号案件中遇到了同样的情况，这个问题https://www.mql5.com/ru/forum/1111/page2124#comment_6518537。

ServiceDesk一开始也报告说，它无法重现这个错误。我花了很大力气才说服自己，毕竟有一个错误......。在最后。

支持团队 2018.02.10 22:35
似乎早在周五就在一台有39张图表的弱机上重现了你的问题。
我们将继续关注它。如果需要，将要求提供额外的数据。谢谢你。

这就提出了一个问题：到底有没有必要为这种错误而烦恼？或者让他们平静地生活......也许他们不会再冒出来--有一台快速的电脑就够了，对吗？

这些问题是在这样的背景下产生的：一打其他图表与几个EA/指标可能会使快速的计算机变成慢速的计算机（而一个普通的交易者恰恰使用了大量的EA - 例如https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82个EA正在运行）...甚至由于其他情况（杀毒软件），一台缓慢的电脑也可能在短时间内变得缓慢。其他程序...或者系统本身已经暂时接管了几乎所有的资源）。

然后恰恰是那种无法解释的100分之一的失败会发生（根据自然法则，它自然会在最不恰当的时候发生）。

[Vladislav Andruschenko]

A100:

因此，在第1530548号 请求中，ServiceDesk无法重现错误https://www.mql5.com/ru/forum/1111/page1628#comment_2702870，即使我现在有稳定的播放（在构建1881）。经过一番思考，我想明白了原因!答案是：因为我有一台慢速的电脑（平板电脑）。

同样的情况也出现在第1952509号申请中，这个问题https://www.mql5.com/ru/forum/1111/page2124#comment_6518537。

ServiceDesk一开始也报告说，它无法重现这个错误。我花了很大力气才说服自己，毕竟有一个错误......。在最后。

支持团队 2018.02.10 22:35
似乎早在周五就在一台有39张图表的弱机上重现了你的问题。
我们将继续关注它。如果需要，将要求提供额外的数据。谢谢你。

这就提出了一个问题：到底有没有必要为这种错误而烦恼？或者让他们平静地生活......也许他们不会再冒出来--有一台快速的电脑就够了，对吗？

这些问题是在这样的背景下产生的：一打其他图表与几个EA/指标可能会使快速的计算机变成慢速的计算机（而一个普通的交易者恰恰使用了大量的EA - 例如https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82个EA正在运行）...甚至由于其他情况（杀毒软件），一台缓慢的电脑也可能在短时间内变得缓慢。其他程序...或者系统本身已经暂时接管了几乎所有的资源）。

然后恰恰是那种无法解释的100分之一的失败会发生（根据自然法则，它自然会在最不恰当的时候发生）。

我的电脑并不弱。但这种文件打开错误也时有发生。

[A100]

Vladislav Andruschenko:
我的电脑并不弱。但这种打开文件的错误也时有发生。

更重要的是，你不是一个普通的用户，你的工作被很多很多人使用。