Android Question "Acces to path... denied" during compilation

Discussion in 'Android Questions' started by chitoq, Apr 10, 2019.

  1. chitoq

    chitoq New Member Licensed User

    Suddenly, I always get this message whenever I try to compile a project. This happens to ALL my current projects. Folders seem to be ok as I can write some files to them.

    B4A Version: 8.00
    Parsing code. (0.00s)
    Compiling code. Error
    Error compiling program.
    Error description: Access to the path 'D:\b4a80\TabStrip\Objects\shell\src\b4a\example\' is denied.
    Error occurred on line: 58
    End Sub

    The sample project above came from the forum. It gave out the same error as the others when compiled. "" will always be there in the error message.

    Kindly help. Thanks.
  2. emexes

    emexes Well-Known Member Licensed User

    So if you go to a command prompt and enter:

    notepad D:\b4a80\TabStrip\Objects\shell\src\b4a\example\

    that works ok? (remember to close that notepad window when done ;-)

    What about if you start a new project from scratch, with just a single Log("Hello") in it?

    The fact that it happens to ALL your current projects is intriguing. Could be a good time to exit all programs, shut the computer down, make a coffee, restart the computer.

    I was going to say that:

    When I look at the paths of on under my B4A directory, they don't have "\shell\" in them

    but I've just noticed that some of them do, and some have both. And when there's both, then they have the same timestamp (well, same minute, anyway, thus from same compilation, not from eg compilations before and after a B4A update) but are different sizes. Hmm. Presumably there is a reason for this.

    Directory of C:\b4a\Muck\BalCase\Objects\shell\src\b4a\muck\balcase

    31/03/2019  04:04 PM             2,337
    1 File(s)          2,337 bytes

     Directory of C:\b4a\Muck\BalCase\Objects\src\b4a\muck\balcase

    31/03/2019  04:04 PM            15,484
    1 File(s)         15,484 bytes
  3. emexes

    emexes Well-Known Member Licensed User

    The \shell\ version of is always 2-3 kB in size, regardless of the size of the other one, so perhaps it is some wrapper process used when in debug mode. Yet another reason to do a total shutdown and restart of your computer; perhaps there is a second copy of B4A running that didn't shut down properly, or a zombie Java compiler process, something like that.
  4. emexes

    emexes Well-Known Member Licensed User

    Tools menu, Clean Project is worth a go too - maybe it cleans up common (non-project-specific) junk too. I doubt it'll fix your problem, but no harm trying.
  5. RJB

    RJB Active Member Licensed User

    I started getting this problem after upgrading to B4A 9. I've had to run it as Adminstrator to get around the problem!
    Possibly there's something else that would solve it?
  6. emexes

    emexes Well-Known Member Licensed User

    If you've been running it as administrator, then presumably any files created are now marked as belonging to the administrator too, which probably means that when you revert back to being a standard user, you can't write to them, maybe can't even read them.

    By changing owner of a .b4a file, I was able to duplicate your "denied" message. Ditto when I remove Write access to the file.

    To view or change security on files, you can right-click on a file, Properties, Security. Or use CACLS in command prompt.

    Changing the owner was a bit iffier - I went in via the right-click method, and Windows said the file belonged to another another used, but let me shift to administrator mode and change the owner anyway. Don't know how you'd do that on all files in a directory tree, though. CACLS is quiet about that. Perhaps you just Ctrl+A select-all and that might be smart enough to do the sub-directories too.
  7. emexes

    emexes Well-Known Member Licensed User

    If none of the above works, the simplest fix might be to archive up the entire D:\b4a80 directory tree using an archiver that doesn't store Windows/NTFS file owner and access control information, then rename the b4a80 directory (rename, NOT delete!), then extract a replacement tree from the archive, which presumably will adopt the current user as owner with full access.

    Probably a good idea to save a just-in-case COPY of that directory tree to another drive first, too.
  8. RJB

    RJB Active Member Licensed User

    I guess the point is, in my case, why did the problem start with B4a 9 when it was OK before?
  9. emexes

    emexes Well-Known Member Licensed User

    Given that it's not a widespread issue, that would suggest it is something that is (or was) different about your situation. Perhaps you were in administrator mode when you installed the update, and thus since then you've had to run B4A in administrator mode, and everything that has been touched by B4A has become unwriteable to non-administrators.

    One test might be: start B4A (not as an administrator) and then create a brand new project and save it to a brand new directory eg c:\b4atest\testproject\Main.b4a and see if you can compile that project (that was wholly created and saved in non-administrator mode).
  10. RJB

    RJB Active Member Licensed User

    Re-booted the PC (which had been running for several months!) and it's working OK now.
    I'll have to remember to re-boot it every now and again!
    Thanks for the suggestions.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice