Forum OpenACS Development: NaviServer on Windows: [ns_logroll] returns "Permission denied"

Request notifications


NaviServer on Windows is unable to perform log-roll apparently.
I've checked, and the "Permission denied" is nonsense, because it even appears if everybody has full access to the file.

I can reproduce the issue on Windows 10, Server 2012 and Windows 7, so I guess it's a general issue.

Please let me know if you (Gustaf probably...) need a Windows system to reproduce the issue.

@Maurizio: Can you reproduce the issue on your OpenACS server?


There's also a section called
"Setting up the logroll" on this page
Hi Maurizio,

Thanks for the links. Right, that was the information I had - that log-roll didn't work and that it was necessary to do a workaround. Sure it's possible to stop NaviServer and remove the log file!

But this is a bug in AOLserver/NaviServer on Windows. This is the bug I'd like to address. In Linux ns_logroll works perfectly.

You can reproduce the bug by entering "ns_logroll" in the /ds/shell. It works on Linux and doesn't work on Windows.

=> It seems only Gustaf and you are capable of debugging NaviServer code at the moment. Is there some chance that you'd look into the issue?



We were just discussing this with Brian. Windows and its permissions policies are causing this issue, the issue is in the call to the C rename function. We patched our AOLServer for Windows long time ago by writing an ugly custom workaround that creates a custom Rename function.

The Ns_RollFile calls CustomRename defined below.

Here is our workaround if you find it useful:

Dear Enrique,

many thanks for sharing the code. ... which is somewhat weird, since the custom "rename" performs actually a copy operation. This indicates, that the actual user of NaviServer/AOLserver has "create" permissions but not "rename" permissions - which are under windows essentially "delete" permissions (as i found though googling).

Stupid question: if this is the case, isn't it easier to give the user the delete permissions for this folder instead of patching the code?

all the best

Thanks for your reply Gustaf.

Back then, We tried all possible combinations of Windows permissions, including Full Admin/Full Control and even granted ownership. It never worked.

So, we decided to give 'CopyFile' a go and it worked. Our feeling was that there was some sort of lock that the standard 'rename'/'copy' didn't like and we didn't have the chance to do more investigation than just using what worked for us back then.

Super duper Enrique! TVM
Dear Enrique,
I have implemented the following changes into my Windows-OpenACS distribution:

static int
Rename(const char *from, const char *to)
int err;
Tcl_Obj *fromObj, *toObj;


fromObj = Tcl_NewStringObj(from, -1);

toObj = Tcl_NewStringObj(to, -1);

#ifdef WIN32
err != CopyFile(from, to, FALSE);
if (err == 0) {
err = Tcl_FSRenameFile(fromObj, toObj);
if (err != 0) {
Ns_Log(Error, "rollfile: failed to rename file '%s' to '%s': '%s'",
from, to, strerror(Tcl_GetErrno()));

return err;

with this change the rolling of the log files works also on Windows.

Once again thank you,

I did find the following piece of text inside TCL's code:

"The many functions in this structure are broken down into three
categories: infrastructure functions (almost all of which must be
implemented), operational functions (which must be implemented if a
complete filesystem is provided), and efficiency functions (which need
only be implemented if they can be done so efficiently, or if they have
side-effects which are required by the filesystem; Tcl has less
efficient emulations it can fall back on). It is important to note
that, in the current version of Tcl, most of these fallbacks are only
used to handle commands initiated in Tcl, not in C. What this means is,
that if a "file rename" command is issued in Tcl, and the relevant
filesystem(s) do not implement their "Tcl_FSRenameFileProc", Tcl's
core will instead fallback on a combination of other filesystem
functions (it will use "Tcl_FSCopyFileProc" followed by
"Tcl_FSDeleteFileProc", and if "Tcl_FSCopyFileProc\"is not
implemented there is a further fallback). However, if a
"Tcl_FSRenameFileProc" command is issued at the C level, no such
fallbacks occur