在 C#/.NET 中访问超出 MAX_PATH 的文件
背景
我需要编写一个最高使用 .NET 2.0 版本的工具(出于政治、商业和保密/信任原因,该客户不可以选择使用现成的工具)来迁移文件通过网络连接到另一个服务器。 这些服务器是本地团队的文件服务器,某些团队文件夹需要迁移到其他服务器以方便重组。 基本思想是我们读取每个文件并在几个小时内通过网络将其流式传输,几天后数据将被迁移。 需要保留文件权限。 由于这将需要几天的时间(对于某些团队来说,我们正在讨论数 GB 的数据),因此我们需要每晚迭代文件并比较修改日期并更新已更改的日期。 理论上,新服务器最终将拥有最新的文件副本,并且用户可以切换到新服务器。 当然不是这么简单,但我们有一个我们认为应该可行的设计:)
问题
所以理论上我们只需打开文件,通过网络传输它,然后将其写入另一个结束了,对吗? :)
不幸的是,在服务器本身上,文件共享是在文件夹路径中创建的,例如:
D:\Data\Team Shares\DIVISION\DEPARTMENT\团队名称 - 可能相当长\
对于每个用户,此路径映射到驱动器,例如,它将作为 \\SERVER\TEAMNAME 共享并映射到 T : 驾驶。
这导致了这样的情况:从 T: 驱动器可见的文件在 MAX_PATH 限制内,但在服务器本身本地查看时,它们远远超出了限制。 我们无法使用网络共享访问文件,因为该工具需要通用,才能在数百台服务器上运行,并且没有标准方法来判断哪些文件共享是我们应该移动的,哪些不是 - 有甚至没有命名约定标准。 此外,有时还会有其他共享的子共享,因此我们会两次超出 MAX_PATH
限制!
我知道使用“\\?\”前缀指定路径的解决方法,该前缀将路径视为 UNC 路径并允许理论上最多 32k 个字符。
此解决方法是在 Win32 API 级别实现的,System.IO 命名空间(大部分)基本上只是本机 Win32 API 函数的薄包装,但是 Microsoft 在将调用交给 API 之前“帮助”实现了额外的(不正确的)验证。 在这种情况下,.NET Framework 拒绝该路径,因为它声明“?” 是无效的路径字符。
所以我的问题是...有没有一种我没有想到的方法可以让我解决这个问题,而不必完全重写几乎整个 System.IO 命名空间,进行大量 P/Invoke 调用,只是为了删除这个烦人的验证?
BACKGROUND
I need to write a tool using .NET version 2.0 at highest (using something off the shelf is not an option for this client for political, commercial, and confidentiality/trust reasons) to migrate files from one server to another over the network. The servers are file servers for local teams, and certain team folders need to be migrated to other servers to facilitate a reorganisation. The basic idea is we read each file and stream it over the network out of hours and after a few days the data will be migrated. File permissions need to be preserved. As this will take a few days (we are talking up to several gigabytes of data, for some teams), we need to iterate over the files each night and compare the modification dates and update those that have changed. The theory is that eventually the new server will have an up to date copy of the files and the users can switch over to the new server. It is of course not quite this simple, but we have a design we think should work :)
THE PROBLEM
So in theory we just open the file, stream it over the network, and write it at the other end, right? :)
Unfortunately, on the servers themselves, the file shares were created at folder paths such as:
D:\Data\Team Shares\DIVISION\DEPARTMENT\NAME OF TEAM - COULD BE FAIRLY LONG\
For each user, this path is mapped to a drive, for example it would be shared as \\SERVER\TEAMNAME and mapped to the T: drive.
This has caused the situation where the files as visible from the T: drive are within the MAX_PATH
limitation, however when viewed locally on the server itself, they go way beyond it. We cannot access the files using the network shares as this tool needs to be generic, to run on hundreds of these servers, and there is no standard way to tell which file shares are ones we should be moving and those which are not - there is no naming convention standard even. Also, occasionally there are sub-shares of other shares and so we exceed the MAX_PATH
limit twice over!
I am aware of the workaround to specify paths using the "\\?\" prefix, which treats the path as a UNC path and allows a theoretical maximum of 32k characters.
This workaround is implemented at the Win32 API level, the System.IO namespace is (mostly) basically just a thin wrapper around native Win32 API functions, however Microsoft have "helpfully" implemented extra (incorrect) validation before handing the call off to the API. In this case, the .NET Framework is rejecting the path because it claims that '?' is an invalid path character.
So my question is... is there a way I haven't thought of that will allow me to work around this without having to completely rewrite the almost the whole System.IO namespace, making a load of P/Invoke calls, just to remove this annoying validation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
BCL 团队制作了一个由 3 部分组成的系列文章,详细说明了做出这些选择的原因以及解决方法。 如果您还没有阅读过,我建议您阅读一下,因为它是有关该主题的重要信息来源
The BCL team did a 3 part series on exactly why these choices were made and what the work arounds are. If you haven't read that yet I suggest you do as it's a great source of information on the subject
我遇到了一个可能有帮助的第三方解决方案:AlphaFS。
I ran into one third-party solution that may help: AlphaFS.
假设您的软件具有必要的权限,通过一些平台调用来解决此限制应该相当容易:
It should be fairly easy to work around this limitation with a bit of platform invoke, assuming your software has the necessary permissions:
您可以尝试通过使用 subst.exe (或其内部使用的任何 API)映射父目录来缩短路径:
http://www.makeuseof.com/tag/how-to-map-a-local-windows-folder-to-a- 理想情况
下,您应该尽可能多地绘制路径。
You could try shortening the path by mapping a parent directory using subst.exe (or whatever APIs it uses internally):
http://www.makeuseof.com/tag/how-to-map-a-local-windows-folder-to-a-drive-letter/
Ideally you'd map away as much as possible of the path.
我已经使用下面的小脚本成功删除了目录结构。 Pushd 使用 UNC 格式,为您提供 32K 而不是 260 的限制
I have had success deleting directory structures using below small script. pushd uses UNC format which gives you 32K instead of 260 limitation