We spotted this issue, as we were trying to read files from a UNC path at which we had only been granted access to the leaf folder, e.g.
\\server\path\to\folder
In the above example, we have read access on folder, but no access on to. When we tried to read certain properties, e.g. LastWriteTime then we would receive an UnauthorizedAccessException.
If the string ends with a wildcard, period (.), or directory name, the user must have access permissions to the root and all subdirectories on the path.
I think that's what is happening here, i.e. it's reading the leaf folder in the context of its parent (to which we have no access). Mapping to a network drive (which meant that the folder then had no parent and caused a different code path to be followed) allowed us to work around the issue. Note that this issue is not limited to UNC paths - the same applies to local file system too, if the permissions are structured as described.
I would really have liked to have created an accurate unit test, but although I can simulate the permissions by modifying access rules, I'm not sure how I'd subsequently tidy up those temporary files on tear down. If anyone has suggestions (e.g. could I execute in the context of a known OS SID?) then I'd be happy to revise this. As it is I've just introduced a couple of very simple unit tests.
We spotted this issue, as we were trying to read files from a UNC path at which we had only been granted access to the leaf folder, e.g.
\\server\path\to\folder
In the above example, we have read access on folder, but no access on to. When we tried to read certain properties, e.g. LastWriteTime then we would receive an UnauthorizedAccessException.
Reading the documentation for FindFirstFile I note that it states:
I think that's what is happening here, i.e. it's reading the leaf folder in the context of its parent (to which we have no access). Mapping to a network drive (which meant that the folder then had no parent and caused a different code path to be followed) allowed us to work around the issue. Note that this issue is not limited to UNC paths - the same applies to local file system too, if the permissions are structured as described.
I've forked the repo and made a simple change:
https://github.com/natwallbank/LongPath
I would really have liked to have created an accurate unit test, but although I can simulate the permissions by modifying access rules, I'm not sure how I'd subsequently tidy up those temporary files on tear down. If anyone has suggestions (e.g. could I execute in the context of a known OS SID?) then I'd be happy to revise this. As it is I've just introduced a couple of very simple unit tests.
I'll create a pull request.