文件共享读写不起作用 (C#.NET)
我正在使用 C# 的十六进制编辑器控件,可以在此处找到源代码和二进制文件。
使用它时的一个问题是,如果在十六进制编辑器和另一个程序中加载文件,则另一个程序无法保存该文件,因为它已经被另一个进程使用。
所以我询问了控件的作者,他告诉我将 FileByteProvider 和 DynamicFileByteProvider 类中的 File.Open 方法中的 FileShare 参数设置为 ReadWrite(最初只是 Read)即可解决此问题。所以我这样做了,但它仍然不起作用(同样的错误)。将其设置为“只写”也不起作用,但将其设置为“只读”和“无”都可以。这些文件在任何程序(例如记事本)中都存在相同的问题。它们没有设置为只读或其他任何东西,所以我不知道为什么它不起作用。
我在这里缺少什么吗?
I'm using a hex-editor control for C#, the source code and binary files can be found here.
One problem when using it was that if a file was loaded in the hex-editor and another program, the other program can't save the file, because it's already being used by another process.
So I asked the author of the control who told me to set the FileShare argument in the File.Open method in the FileByteProvider and DynamicFileByteProvider class to ReadWrite (it was originally only Read) would fix it. So I did that, but it still didn't work (same error). Setting it to Write only also didn't work, but setting it to Read only and None both work. The files have the same problem in any program, for example Notepad. They aren't set to ReadOnly or anything, so I have no idea why it doesn't work.
Is there anything I am missing here?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
问题可能出在另一个程序上 - 如果它尝试打开文件以进行独占访问(不共享),那么无论你的程序如何打开该文件 - 它都会失败。
每当程序尝试打开文件时,您都需要指定 FileAccess 和 FileShare 参数(如果未显式传递,则采用默认值)。
然后 Windows 要做的就是检查所有现有的打开文件句柄,并确定它们是否兼容。因此,它将您的 FileAccess 参数与其他人的 FileShare 参数进行比较 - 您是否可以执行其他人所说的他们乐意做的事情? 然后它执行相反的检查 - 您的 FileShare 参数是否允许与他们的 FileAccess 参数匹配吗? - 他们正在做您乐意做的事情吗?只有当两项检查都通过时,您的特定开放请求才能获得批准。
您可以使用进程监视器之类的东西来实际观察发出到<的Win32调用a href="http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx" rel="noreferrer">CreateFile 查看每个进程实际在做什么。
记事本可以打开以读/写方式共享的文件,但无法写回该文件。示例程序:
设置给定的断点,运行程序。当遇到断点时,打开记事本,然后用它打开 C:\Bar.txt。一切都很好。向文件添加更多文本并点击“保存”。您会收到一条错误消息。
The problem might be with the other program - if it's trying to open the file for exclusive access (with no sharing), it doesn't matter how your program has opened the file - it's going to fail.
Whenever a program tries to open a file, you specify a FileAccess and FileShare parameter (or defaults are taken if they're not explicitly passed).
What Windows then has to do is check all existing open file handles, and determine whether they're compatible. So it compares your FileAccess parameter against everyone else's FileShare parameters - are you allowed to do what everyone else has said they're happy for others to do? And then it performs the opposite check - does your FileShare parameter match up with their FileAccess parameters? - are they doing things that you're happy for them to be doing? Only if both checks pass can your particular open request be approved.
You can use something like Process Monitor to actually watch the Win32 calls being issued to CreateFile to see what each process is actually doing.
Notepad can open a file that's been shared for Read/Write, but it can't write back to the file. Sample program:
Set the given breakpoint, run the program. When it hits the breakpoint, open Notepad, and use it to open C:\Bar.txt. Everything is fine. Add more text to the file and hit save. You'll get an error message.
可能,您没有正确关闭该文件,因此即使在您关闭应用程序后它仍然保持打开状态(之前的权限设置为“读取”)
Possibly, you weren't closing the file appropriately so it remained open even after you closed your application (with previous permissions set to Read)