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

[chitoq]

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\main.java' 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. "main.java" will always be there in the error message.

Kindly help. Thanks.

 

[emexes]

So if you go to a command prompt and enter:

notepad D:\b4a80\TabStrip\Objects\shell\src\b4a\example\main.java

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 main.java 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 main.java
               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 main.java
               1 File(s)         15,484 bytes

 

[emexes]

The \shell\ version of main.java 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.

 

[emexes]

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.

 

[RJB]

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.

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?

 

[emexes]

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.

 

[emexes]

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.

 

[RJB]

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.

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

 

[emexes]

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

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).

 

[RJB]

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).

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.