Don't lock log file against shared reading.

[mitchcapper]

It is great there is an error log now but you can't read it unless you unload the extension:

cat shell.log
cat.exe: shell.log: Permission denied

I don't see the negative in allowing shared read access?

[RubicBG]

I understand what you're saying, but I personally don't have enough information to confirm whether it's a "problem" or not.

• I can see the log content in VS Code as it updates in real time, so for me, it’s accessible without unloading the extension.
• That said, there are users who’ve reported they can’t edit NSS files due to permission restrictions, and that might be related here too.

One possibility is that the log file is being written to a protected directory like: C:\Program Files\Nilesoft Shell If that's the case, it would make sense — Windows often blocks read/write access to system folders for non-admin users, which would explain why tools like cat.exe return a Permission denied error.

• Relocate or install Nilesoft Shell to a less restricted path like: C:\Nilesoft Shell
  This avoids the special protections applied to C:\Program Files, which often block read/write access for standard users.
• Try running your terminal (e.g., Command Prompt, PowerShell, or Git Bash) as Administrator
• Some editors (like VS Code, Notepad++) can read files even when they’re locked or restricted.

PS:

• i tested cat shell.log and it works for me
• there maybe a solution with Symbolic Link as well (but I've never experimented in such a situation, so it's just in theory)

[mitchcapper]

I agree with you something odd here after looking at it further. While windows does protect C:\Program Files\Nilesoft Shell against writes by default reads that would not be the case on (especially as explorer should be running as the same user).

What is odd though is explorer was holding the lock on the file. I used process monitor to verify it was the only thing with handles open and my shell history does match my memory:

I had access denied several times, tried copying which also failed, killed off explorer then could read it no problem then restarted explorer. At the time I was trying to debug errors in my config (where it wasn't displaying any context) so I am not sure if related as it does seem Shell handles errors gracefully. I will see what I can reproduce further as I can also read it without issue right now.

Thanks for the various attempts/suggestions here.

[mitchcapper]

OK so I have some more slightly helpful information (but no easy repro).

*) It seems like Shell when going to write to the log does open it with a read/write lock, appends its message, and releases it. This means if something has the file open for reading it doesn't write the log (ie if tailing the log). Other apps (ie notepad) can open and write it but im guessing it is the read lock that causes the problem. This isn't exactly related but a quirk.

*) Given Shell doesn't seem to just hold open shell.log with normal operating (even when you cause an error to occur so it must write to it) it closes right away so the handle shouldn't show as actually open. This is the behavior I generally see.

After shell has been running for hours though I do find that the shell.log file is locked. In addition when I use process explorer to find any handles to shell.log now explorer has many open handles to it:

Sadly I haven't figured out how to reproduce it. Causing an error and restarting explorer it opens write the error and still closes it. Already running explorer causing an error reloading still no issue.

Still somehow its leaking the file handle and that would seem to fit the "lock" issue. I did move the location and permissions are fine but the same command that initially works does not once it starts to be held:

C:\test\NilesoftShell> icacls .\shell.log
.\shell.log BUILTIN\Administrators:(I)(F)
            NT AUTHORITY\SYSTEM:(I)(F)
            BUILTIN\Users:(I)(RX)
            NT AUTHORITY\Authenticated Users:(I)(M)

Successfully processed 1 files; Failed processing 0 files
PS C:\test\NilesoftShell> type shell.log
Get-Content: The process cannot access the file 'C:\test\NilesoftShell\shell.log' because it is being used by another process.