Mounting TAPoR drives on Windows and Mac machines
We have long struggled with the issue of how to provide easy access to data on the TAPoR servers for students and researchers working on projects. The ideal, especially for XML markup projects, is to have a TAPoR share mounted as a network drive; this enables oXygen to provide an easy project editing interface through "Link to external folders", and files can be opened and saved transparently on the server in this way. On Linux this is (naturally) easy. This is what I have learned from trying to do this for CC on her Mac and Windows laptops over the last two days:
- In our labs, we use taporshare.tapor.uvic.ca, which provides an SMB connection. However, this is problematic for laptops and remote locations, because SMB is insecure, and it's also blocked by default on the UVicDefault wireless network.
- Macs do not support SFTP connections out of the box.
- Oxygen promises to support opening and saving of files over SFTP, but it seems to work only for one file at a time, which makes validation difficult, and it's difficult to set it up so you can browse the folder tree on the server. After a restart, oXygen also seemed to lose the logon credentials and be unable to ask for them again, causing "Auth fail" errors. Hopeless.
- MacFuse and MacFusion (search the web) worked well for me on Snow Leopard from home, connecting to Lettuce, but were hopeless on Leopard; we had endless authentication issues, and were unable to save files to the server.
- On Windows, you can use Dokan SSHFS (search the web) to mount a share (e.g. Lettuce, or nfs.tapor.uvic.ca) over SSH. This works OK, except that the GID setting is not respected when creating new files; they end up as user:user instead of user:project. Still, it's better than nothing.
- On the Mac, the only solution we could find was to use Transmit, which costs money, but which will allow you to open a remote files over an SFTP connection. The only issue here was the problem with validation; the relative link to the schema did not work, of course, because the file was opened in oXygen from a temp folder. We were able to work around it by placing copies of schemas in the temp folder, in the right relationship (fortuitously) to the place where Transmit stashes its temporary files when you open a file from the server.
All in all, very unsatisfactory. This precludes people working remotely on our project data unless they're relatively sophisticated and can use something like subversion, can be relied upon to use a client such as WinSCP or Cyberduck correctly, or are using Linux.