Using \\Server\Share\Path Path Specifications

[Bob_Schor]

This is a "Word to the Wise" note regarding a trap I set for myself and into which I fell.

Background:

     I'm designing Data Acquisition and Analysis routines, where the program will be run on one computer, with the data being saved on one of several computers.  The name of the Series and the LabVIEW Project is Murine, and the Top Level Folder for all of the Murine Data is also called Murine.  Within this Folder, there is a hierarchy of sub-folders following a more-or-less logical naming scheme.

     To avoid having to "guess" or "know" where the Murine folder would be located on each of the possible Target machines (whose names I knew), I chose to mark the Murine folder, wherever it was located, as Shared, with the Share Name also being Murine.

     When the program(s) begins, it asks the User where (on which Computer) the data are located, and saves this as "Server".  It then builds a Path to the Top Level Murine folder using the construct \\<Server>\Murine, i.e \\<Server>\Share.

The Problem:

     I'm currently "on the road" with my Laptop, running Windows 10.  Murine has been running and generating data files just fine, but now I'm developing some additional analysis routines.  I've got some Murine data on my Laptop, have created a Murine Share, and went to test my code.  Oops, Error 8 when doing some (but not all!) File I/O functions!

Explanation:

     Error 8 says "File permission error. You do not have the correct permissions for the file."  What?  [Did I read the Error Message carefully?  No.  Did I believe it?  No.  Was I correct in my thinking?  No!!].  "But it's been working on the Windows 7 machine(s) that have been used to take the data -- must be a Windows 10 thing ..."  Well, maybe, but largely No.

     What happened is that (drum roll, please ...) Shares have Permissions.  When I shared the Murine Folder and thereby created the Murine Share, I discovered that the Share had the permissions that "Everybody" had Read access, and that was the only Permission.  [One other case I saw was that the Administrator Group also had some Permissions, but I fell under the "Everybody" class].

Solution:

     When working with Shares, "Everybody" is a problem, as that means that you don't even need to be logged in to gain access (you can come in via Network access).  I fixed this by adding "Authenticated Users" (which means you need to log in) and giving them "Change" Permissions, which is the general Read/Write permission.  Now things work as expected, and also as I was observing on my Windows 7 machines (where, possibly "by accident" or by "bad default", "Everybody" had Full Control, which I also do not recommend!).

Bob Schor