Access denied

[KenDown]

Can anyone tell me why the bit of code here throws up an "Access denied" error? I get the same error if I don't delete the temporary file but then call the routine a second time (which would try to overwrite Temp.bmp)

Reading the help file indicates that to clear images out of memory one needs to call PROC_imgExit followed by PROC_imgINIT and doing so does indeed allow me to delete the file, but it also disables the library so that no further images are displayed.

Code: Select all

      INSTALL @lib$+"ImgLib"
      PROC_imgInit
      l%=0:t%=0:w%=1920:h%=1080
      OSCLI("SCREENSAVE "+@dir$+"Temp.bmp "+STR$l%+","+STR$t%+","+STR$w%+","+STR$h%)
      t%=FN_imgLoad(@dir$+"Temp.bmp")
      OSCLI("DEL "+CHR$34+@dir$+"Temp.bmp"+CHR$34)

[baz4096]

Hi Ken,

We had a web hosting outage earlier that prevented Richard from replying to this post.
Richard's message would have been as follows:

Can anyone tell me why the bit of code here throws up an "Access denied"
error?

@dir$ is the directory containing your
BASIC program, as such you should never attempt to write to
it since it may be read-only - and is likely to be if you
'compile' your program to an executable. The only pre-defined
directories to which you may safely write are
@tmp$ and @usr$.

Also, it makes no sense to put a file path in quotes in the *DEL command
but the same path not in quotes in the *SCREENSAVE command:

Code: Select all

       OSCLI("SCREENSAVE "+@dir$+"Temp.bmp
"+STR$l%+","+STR$t%+","+STR$w%+","+STR$h%)
       OSCLI("DEL "+CHR$34+@dir$+"Temp.bmp"+CHR$34)

If quotes are needed (and they generally will be) they are needed in
both.
--------------------------------------------------------------------

Richard.

[KenDown]

Thank you, Richard.

My program (which is compiled) is on my D: drive, but can equally well run off a USB stick or other portable drive, so access permissions should be fine. However when I changed @dir$ to @usr$ or @tmp$ everything worked as expected and the file deleted happily. Is this some deliberate restriction on @dir$? Is there a work-around?

You are correct about the quotes. I stuck them in out of desperation. * commands don't usually need them unless there is a space or some other "illegal" character in the filename.

[Richard Russell]

My program (which is compiled) is on my D: drive, but can equally well run off a USB stick or other portable drive, so access permissions should be fine.

If your program is running from a USB stick you would surely not want to write to the stick and risk corrupting it, for example if the user were to unplug it without first going through the 'safely remove' procedure? That sounds like a classic case where you would want @dir$ to be read-only.

Is this some deliberate restriction on @dir$?

Generally a program will be stored in a location which is not normally writable, not least for security reasons. Being able to modify a program or its support files (e.g. libraries/DLLs) without administrative privileges would make it trivially easy for malware to infect it, or for accidental corruption to damage it.

That's why, in Windows, there are areas of the file system called Program Files, which is not user-writable, and Program Data (for non-user specific data) and Application Data (for user-specific data), which are; other operating systems have similar divisions in the file system.

So, yes, ensuring that a program is stored somewhere non-writable is "deliberate".

Is there a work-around?

Why would you want a "work-around" for a key security feature that protects you and your users? If you need to write to the directory containing your program then do it 'As Administrator' (that's how installers work).

That's not to say that you can't store your program in a user-writable location, you can, but it's extremely risky and should be done only if you are fully aware of the potential consequences.

* commands don't usually need them unless there is a space or some other "illegal" character in the filename.

...or in the path. That's the crucial point: @dir$ (and @tmp$, @usr$) will very commonly contain characters which require the entire path to be enclosed in quotes. And of course you have no idea what they will be on the target machine running your program. So whenever using one of those pre-defined path variables you must always add quotes.

All this is standard stuff, and much of it applies to other programming languages too.