"Access denied" in the console window

[GCRaistlin]

"Copy updates for selected products into directory" (i. e. CopyToTarget.cmd) displays "Access denied" 4 times. This code:

Code: Select all

if exist %DOWNLOAD_LOGFILE% (
  echo.>>%DOWNLOAD_LOGFILE%
  echo -------------------------------------------------------------------------------->>%DOWNLOAD_LOGFILE%
  echo.>>%DOWNLOAD_LOGFILE%
)
if exist .\custom\InitializationHook.cmd (
  echo %DATE% %TIME% - Info: Executed custom initialization hook ^(Errorlevel: %ERR_LEVEL%^)>>%DOWNLOAD_LOGFILE%
  set ERR_LEVEL=
)


is responsible for this. The existence of the log file doesn't mean that it is writable...

[Dalai]

Without having checked this in detail I suggest to add a check if the file is writable:

Code: Select all

if exist %DOWNLOAD_LOGFILE% (type NUL >>%DOWNLOAD_LOGFILE%) 2>NUL || (
    echo %DOWNLOAD_LOGFILE% is NOT writable!
    goto Error (or whatever label handling the error)
)

Note that the OR part using the two pipes (||) MUST be written like this, because the type command doesn't set any errorlevel, so it's not possible to check for its value. The download.log will not be modified in any way even if it's writable because NUL is a special reserved name.

Checking the file's existance is optional, i.e. this would work as well:

Code: Select all

(type NUL >>%DOWNLOAD_LOGFILE%) 2>NUL || (
    echo %DOWNLOAD_LOGFILE% is NOT writable!
    goto Error (or whatever label handling the error)
)

The only small drawback is that the file is created if it doesn't exist.

Regards
Dalai

[GCRaistlin]

It's easier just to redirect stderr to nul:

Code: Select all

2>nul (
  if exist %DOWNLOAD_LOGFILE% (
    echo.>>%DOWNLOAD_LOGFILE%
    echo -------------------------------------------------------------------------------->>%DOWNLOAD_LOGFILE%
    echo.>>%DOWNLOAD_LOGFILE%
  )
  if exist .\custom\InitializationHook.cmd (
    echo %DATE% %TIME% - Info: Executed custom initialization hook ^(Errorlevel: %ERR_LEVEL%^)>>%DOWNLOAD_LOGFILE%
    set ERR_LEVEL=
  )
)


[Dalai]

Well, then you wouldn't see any error messages, but you wouldn't have ANY download.log either. Doesn't make much sense, does it? Remember that there are several occurances of redirection to download.log (or calls to a new label when taking the implementation of my suggestion in r1026/r1027 into account).

A log file that can't be written to is a good and valid reason to abort the script altogether, IMO. Hence my suggestion above.

Regards
Dalai

[GCRaistlin]

With [x] Copy updates for selected products into directory and [x] Only prepare ISO / USB we don't need download.log at all, do we?
I use this combination of checkboxes when I want to install updates on a clean machine. WSUS Offline Updates folder is on the network share with read-only access. I have to make a local copy because Auto Recall feature requires anonymous access to the share which I consider unacceptable.
So it is expected that we can't write to the log there.

[Dalai]

You can copy the wsusoffline\client directory manually to the client, can't you? I don't see a need to start UpdateGenerator at all in such a case.

Regards
Dalai

[GCRaistlin]

There's more than one product the updates are downloaded for in my WSUS Offline Updates folder. I don't want to copy 15 GB instead of 5 GB over the network.

[WSUSUpdateAdmin]

Hi.

[...]The existence of the log file doesn't mean that it is writable...

So please make it writable again!
It's the first time in twelve years that someone makes (parts of) the download repository write protected and is surprised about errors afterwards.
The log file is supposed to be writable as well as the client subtree, and I won't add a single line of code to check that, sorry.

Regards
Torsten Wittrock

[GCRaistlin]

Personally, I don't care about these errors as I already found out what's the reason. I just wanted to help making the product better - if these errors look strange for me (as I am just creating a local copy and have read rights to the source and write rights to the target - so what access can be denied for me?) they may look the same for others.

[WSUSUpdateAdmin]

Thanks!