我们正在开发一个基于web的应用程序，该应用程序提供用户案例文件的存储库。希望用户能够从具有完全读写功能的网络浏览器访问这些内容。
对于我们的上一代系统，该系统托管在带有Windows客户端的本地Linux服务器上，我们能够共享一个文件夹，并使用\\server\share_name\file.doc类型的链接进行访问。如果这些类型的链接包含在网页中（在internet explorer中），并单击在MS Word中打开的文件，并且可以直接保存到共享文件夹中。然而，这些类型的链接只在IE中工作，而不是FF或Chrome
现在在我们的下一代系统中转向基于互联网的解决方案，我们需要类似的功能。
我们正在考虑让WebDAV（或FTP/SFTP）共享，并将每个客户端机器上的本地驱动器映射到它，以提供类似的功能。不过，这可能无法很好地与FF或带有\\server\share_name的Chrome配合使用。。。键入链接。我们已经做了简短的测试，文件：//链接在打开文件后不提供写入功能。
作为最后的手段，我们将能够使用手动文件上传对话框，但这并不理想，需要额外的最终用户培训。
在该领域有任何类似的经验以及任何可能的解决方案/最佳实践。
当您将远程资源映射为本地驱动器时，对于浏览器来说，这将成为本地驱动器。浏览器对本地文件系统的访问权限有限。现在，当你向浏览器提供链接时，浏览器的默认行为是下载链接后面的资源，然后让本地应用程序处理它。浏览器只是不知道如何以不同的方式在本地打开远程资源。
解决方案是让浏览器下载一些东西（某种链接文件），并让一些本地帮助模块（外部应用程序或浏览器插件）打开该链接文件，然后在本地打开该链接中指定的位置。由于这将是一个客户端助手模块，它将能够与客户端系统交互，并知道如何打开所提供的链接。考虑到每个系统上的虚拟驱动器号可能不同（如果将磁盘装载到驱动器号），辅助模块将需要解析链接以指向正确的本地驱动器。如果您创建了一个隐藏的虚拟驱动器（我们的虚拟存储产品允许您这样做），则链接将显示为"\SomeFancyNameUniqueToYourApp\Path\To\File.ext"，并且无需进行解析。而且大多数应用程序都能很好地处理这种类型的路径。
我不确定，但浏览器可能会在不需要助手模块的情况下打开Windows.lnk文件，使用隐藏的虚拟驱动器，你可以在服务器上生成一个lnk文件，并让浏览器在本地打开它。但这只是猜测。我敢打赌，无论如何你都需要一个助手模块。
ftp://username:password@主机名/类型链接应该可以工作，并且MS应用程序在处理它们方面越来越好。仍然不是100%，尽管
试试SMEStorage.com。它们使您能够映射本地WebDav和FTP服务器，并在Linux、Mac或Windows上使用云驱动器访问文件，还可以从移动设备（iOS、Android、BlackBerry和Windows Phone 7）访问文件。您可以为每个文件获得唯一的文件链接，也可以在链接过期时获得安全的文件共享。