0

An internal application in our company requires files aa, bb ... zz in folder X to be read upon startup. When I (as someone with FullControl access to folder X) launch the app, all goes fine. When any of my colleagues (who only have Read access to folder X) launch the app, they get an "Access denied to file aa ... " exception.

The files are being read by the following routine

        public static void readFromBinaryFile(this QIHasFileIo xThis, string xFilePath)
        {
            if (!System.IO.File.Exists(xFilePath))
                throw new System.Exception("File to read " + xFilePath + " does not exist ... ");

            if (xThis == null)
                throw new NullReferenceException("xThis cannot be null, as it is a readonly reference ... ");

            using (BinaryReader xReader = new BinaryReader(new FileStream(xFilePath, FileMode.Open, FileAccess.Read)))
                xThis.readObject(xReader);
        }

i.e. I am specifying the Read mode, which should in turn require only Read access to the folder. When my colleagues go to folder X in Explorer, then can copy the aa, bb, ... files to their Desktops, which means they DO have Read access to the files.

So I am intrigued. This weird behaviour started with changes to the data server a couple days ago. The most notable changes were that 1/ my colleagues stopped having admin rights on the data server 2/ some GPO's might have been messed up (it happenned before in the company). The IT department is baffled as well, so I have no clue how to proceed.

Any hint is much appreciated, Daniel

Edit: An already deleted post proposed using FileShare.ReadWrite. I am grateful to the author for the comment, however the file is guaranteed not to have a write-lock on it. Hence, the why File.copy works but File.OpenRead prompts access denied? thread is not relevant here.

Community
  • 1
  • 1
Daniel Bencik
  • 959
  • 1
  • 8
  • 32
  • Is the file being written to / accessed by another process at the same time? – Baldrick Jun 23 '16 at 08:24
  • If so, you need to add `FileShare.ReadWrite` to the parameters passed to the `FileStream` constructor. This prevents it trying to get an exclusive read lock. – Baldrick Jun 23 '16 at 08:25
  • Possible duplicate of [why File.copy works but File.OpenRead prompts access denied?](http://stackoverflow.com/questions/28087927/why-file-copy-works-but-file-openread-prompts-access-denied) – Baldrick Jun 23 '16 at 08:27
  • No, the files are "constant" - they get written to once a year. There is no write lock on them. Even so, I tried to solution with `FileShare.ReadWrite` to no avail. – Daniel Bencik Jun 23 '16 at 09:40
  • Can they open the file using say notepad, or just copy it from windows explorer? – Baldrick Jun 23 '16 at 11:00
  • @Baldrick: Wow. They can open the file using Notepad. – Daniel Bencik Jun 23 '16 at 11:20
  • So your `FileStream` constructor has the wrong flags somehow. Can you try running Procmon.exe on your process, and then on Notepad - look for the CreateFile windows API calls, and see what the exact requests are. From the difference, you can work out what you're doing differently. – Baldrick Jun 23 '16 at 11:24
  • @Baldrick: I was not in th office today and there was some miscommunication with my colleagues. The FileShare.ReadWrite did solve the problem. Can you post it so that I can accept an answer? – Daniel Bencik Jun 23 '16 at 14:22

2 Answers2

1

I had similar problem while reading a file. The issue was with the level of access for the ActiveDirectory group for the particular group (readers group) of users was not setup correctly. I am not sure if you are using AD group authentication on the server. I would recommend you to check the type of access and groups your colleagues have. Also, you need to check how your application is currently authenticating the users to access the directory.

Souvik Ghosh
  • 4,456
  • 13
  • 56
  • 78
  • Thanks. Currently, the app per se does not have any auth in place (we are a small company) so the app accesses the files with the Windows login information. As for the group ... can you please remember more, some keyword or something so that I can give our IT some hint? Many thanks. – Daniel Bencik Jun 23 '16 at 09:43
  • Thanks for the details. As you have mentioned that you are using Windows login, you have test by hit and trial method Just suggesting you few ways- 1. Check if the directory (or the particular file) is manually accessible by the user. 2. Try giving a user full access and test it. 3. Try creating another file share path outside of the current directory where the user have proper access to the files – Souvik Ghosh Jun 23 '16 at 10:46
1

You need to add FileShare.ReadWrite to the parameters passed to the FileStream constructor.

This prevents the application trying to get an exclusive read lock, which might not be possible under some conditions where a shared read-write lock is possible (such as the file being left open for writing by another process).

Baldrick
  • 11,712
  • 2
  • 31
  • 35