3

We are developing a web based application which provides a repository of users case files. Would like the user to be able to access these from their web browser with full read write capability.

For an earlier generation of our system, which was hosted on a local Linux server with Windows clients we were able to share out a folder and access it with \\server\share_name\file.doc type links. If these type of links were included in web pages (in internet explorer) and clicked on the file opened in MS Word and was savable directly into the shared folder. These type of links however only worked in IE - not FF or Chrome

Moving now to an internet based solution in our next generation of the system, we require similar functionality.

We are toying with the idea of having a WebDAV (or FTP/SFTP) share and mapping a local drive on each client machine to it to provide similar functionality. This though will probably not work well with FF or Chrome with \\server\share_name... type links. We have done brief testing and file:// links do not provide write capability once the file is opened.

As a last resort we will be able to use manual file upload dialogs, but this is not ideal and would entail additional end user training.

Has anyone any similar experience in this field and any possible solutions / best practice.

Conor
  • 31
  • 1
  • 1
  • 2
  • Welcome to SO. You can update your own question by editing it. You can vote for questions (upvote or downvote) and if you get the answer that satisfies your needs and answers your question, you can mark it as an answer – Eugene Mayevski 'Callback Jun 28 '11 at 11:30

3 Answers3

2

When you map remote resource as a local drive, for a browser this becomes a local drive. And browsers have only limited access to the local file system. Now when you provide a link to the browser, the browser's default behavior is to download the resource behind the link, and then let the local application process it. The browser just doesn't know how to open the remote resource locally in a different manner.

The solution would be to let the browser download something (some kind of link file) and have some local helper module (external application or browser plugin) open this link file and open the location, specified in this link file, locally. As this would be a client-side helper module, it will be able to interact with the client system and will know how to open the provided link. Given that the virtual drive letter can be different on each system (if you mount the disk to the drive letter), the helper module would need to resolve the link to point to the correct local drive. If you create a hidden virtual drive (our virtual storage products let you do this), then a link would look like "\SomeFancyNameUniqueToYourApp\Path\To\File.ext" and no resolving would be necessary. And most applications handle this type of paths fine.

I don't know for sure, but it's possible that browsers will open Windows .lnk files without a need in helper module, and with hidden virtual drive you could generate an LNK file on the server and have the browser open it locally. But this is just a guess. My bet is that you will need a helper module anyway.

Eugene Mayevski 'Callback
  • 45,135
  • 8
  • 71
  • 121
1

ftp://username:password@hostname/ type links should work, and MS apps are getting better at handling them. still not 100% though

Tom
  • 11
  • 1
0

Try SMEStorage.com. They enable you to map local WebDav and FTP servers and access files using a Cloud Drive on Linux, Mac or Windows, and also from mobile devices (iOS, Android, BlackBerry and Windows Phone 7). You can get unique file links for each file and also secure file sharing in which the links expire.

Neil Shorey
  • 1