Bug? Code behaves differently in debug and release

[Troberg]

This simple code works as it should in Debug (both rapid and legacy), but it doesn't work in Release.

Try
    File.Delete(FilePath ,FileName)
    Msgbox(FilePath & CRLF & FileName,"Deleted")
Catch
    ToastMessageShow("Couldn't delete file: " & FileName, True)
End Try

The MsgBox is just there to test that I actually get there.

When run in debug, the file is deleted, as expected. When run in release, nothing happens. The File.Delete is run, but the file remains. No error is thrown, and I get the MsgBox, so execution at least reaches that line.

Am I just very stupid and missing something obvious, or is this a compiler bug?

Edit: I have, of course, checked filename and path, and it's correct and the same.

Edit 2: Same strange results on two different devices.

 

[LucaMs]

I just tried it and it works.

 

[eps]

Maybe the Catch is 'hiding' an error?

Just to be clear you are running the debug and release code on an actual device and for both it's the same device?

What is the FilePath? What Android versions?

 

[LucaMs]

Maybe the Catch is 'hiding' an error?

This is unlikely, given that the msgbox is shown.

 

[Troberg]

Strange, your program works for me, but not mine.

I've even resorted to this desperation (without success):

    Dim n As Int
    Do While n<100 AND File.Delete(FilePath ,FileName)=False
        DoEvents
        n=n+1
    Loop
    If File.Exists(FilePath ,FileName) Then
        Msgbox(FilePath & CRLF & FileName,"Fail")
    Else
        Msgbox(FilePath & CRLF & FileName,"Success")
    End If

The path is /storage/extSdCard/test and the filename is a random (only a-z and -) 30 character string, with an mp4 extension.

 

[Troberg]

Android versions are 4.2.2 and 4.1.2.

Commenting out the Try-Catch made no difference.

 

[LucaMs]

Try to use the function File.Combine, for path.
For tests, don't use "random names".

 

[Troberg]

Are there any differences in permissions in debug and release? Could it be that debug runs under some B4A credentials, but release runs under another set of credentials?

 

[Troberg]

Try to use the function File.Combine, for path.

What use would that be? I need path and file separated to delete? You mean I should first combine, then pick them apart again?

For tests, don't use "random names".

The names are previously generated test files, so they are fixed and OK. They are not generated on the fly, and the name is the same in debug and release. It's just a bunch of files I generated as a test set, which I then reuse for each test shot. Shouldn't be any problem.

Also, they are not completely random, they follow a pattern like this:

ababyp-inazir-opeqyg-isavet-elyguj.mp4

Five groups of six alternating consonants and vowels, separated by a dash, all lowercase. I would be very surprised if they were bad.

 

[LucaMs]

Are there any differences in permissions in debug and release? Could it be that debug runs under some B4A credentials, but release runs under another set of credentials?

Have you tested the micro project that I have attached in both modes?

 

[LucaMs]

What use would that be? I need path and file separated to delete? You mean I should first combine, then pick them apart again?

File.Combine can be useful to be sure of paths like File.DirAssets, DirDefaultExternal, etc. and of right number and type of slash-backslash (sorry, my english is terrible, I know).

 

[Troberg]

Yes, and it works in both modes. However, my project still don't. A possible difference could be that my project deletes (or is supposed to delete...) a file on the external SD card (/storage/extSdCard/test). I've been browsing the forums and found a probably similar problem, which I would guess depends on the File object not behaving the same if you just use a string path, as opposed to a File.* path.

http://www.b4x.com/android/forum/threads/file-delete-not-working.27952/#post-162324

However, I get my path from a file dialog, and it's not that easy to get a File.* path that way...

 

[Troberg]

Combine does not help.

 

[LucaMs]

Yes, and it works in both modes. However, my project still don't. A possible difference could be that my project deletes (or is supposed to delete...) a file on the external SD card (/storage/extSdCard/test). I've been browsing the forums and found a probably similar problem, which I would guess depends on the File object not behaving the same if you just use a string path, as opposed to a File.* path.

http://www.b4x.com/android/forum/threads/file-delete-not-working.27952/#post-162324

However, I get my path from a file dialog, and it's not that easy to get a File.* path that way...

Yes, that is the problem.

You can solve it looking good on the site, now I have to go, sorry.

 

[Troberg]

Strangely, it works if I do what the other guy in the linked thread did, add a dummy copy after the delete:

File.Delete(FilePath ,FileName)
Try
    File.Copy(File.DirAssets,"dummy.fil",File.DirRootExternal,"dummy.fil")
Catch
    'Log("Ignore this error")
End Try

However, I found that it doesn't have to be a File.Copy, a dummy call to File.Exists also works, and is a little bit less ugly, so I use:

File.Delete(FilePath ,FileName)
File.Exists(File.DirRootExternal,"dummy.fil")

Remove the File.Copy or the File.Exists and the File.Delete fails.

I think I'll have to call this a bug in the compiler. My guess is that something isn't closed, released or finished properly in some cases, and calling another method causes it to be done.

 

[LucaMs]

Most likely I'm wrong but ...

Have you tried to check if the file exists despite its deletion using another way instead of using the Exists?
Using a File Explorer on the device or Eclipse?
I have the impression that File.Exists does not work well in this case.

Try to delete the file, do not copy any files, do not use File.Exists. Verify that the file has been deleted using one of the methods that I have written.

 

[Troberg]

Most likely I'm wrong but ...

Have you tried to check if the file exists despite its deletion using another way instead of using the Exists?
Using a File Explorer on the device or Eclipse?
I have the impression that File.Exists does not work well in this case.

Try to delete the file, do not copy any files, do not use File.Exists. Verify that the file has been deleted using one of the methods that I have written.

It's a video file, and I can close the app, start it again and play the file again, without resetting the test environment, so, yes, it definitely still exists, no doubt about that. Even if I delete a dozen files, I can still play all of them, so it's not even some caching going on.

 

[Erel]

Probably a permissions issue. When you write File.DirRootExternal or DirDefaultExternal the compiler adds the android.permission.WRITE_EXTERNAL_STORAGE

The debugger also adds this permission as it is required by the debugger.

You can manually add it with the manifest editor:

AddPermission(android.permission.WRITE_EXTERNAL_STORAGE)

 

[Troberg]

Yep, that worked.

Still, we have an interesting issue in that it works when I do the File.Exists afterwards. Have we found some way to bypass Android security? Or does File.Exist add the android.permission.WRITE_EXTERNAL_STORAGE, even though it isn't a write operation?

 

[Erel]

Or does File.Exist add the android.permission.WRITE_EXTERNAL_STORAGE, even though it isn't a write operation?

Yes.