win32: source file exclusive access locks

[neolit123]

hello,

i've just tried the current 'master' branch with 'ant install' on the latest AIR SDK / win32.

it works great, but one problem that i've noticed is that if you run 'compile 1' on the simplest of Main.as projects with a deliberate small error you will find that after MXMLC displays the error, java.exe locks the file (assuming LockFile() from the WINAPI) and the file cannot be changed until ASCSH is stopped (i.e. the jave.exe process is stopped) or the file is manually unlocked by another process.

this issue prevents fixing errors / warnings in any source file that was just compiled by MXMLC via ASCSH.

any possible solutions?

[jcward]

Fascinating. Since ascsh is a thin wrapper around MXMLC, it knows nothing about source files, and MXMLC provides very few public functions.

I wonder why FlashDevelop users (also win32) don't see this issue. Maybe FD unlocks source files manually? @elsassph - any idea about MXMLC locking source files?

Hmm, the solution may have to be some external script that manually unlocks the source files.

[elsassph]

We don't do anything special to unlock the files and never saw this behaviour - does that happen with previous versions of the AIR SDK?

[neolit123]

yes,
just tried and it happens with AIR SDK 13 as well.

FD is not affected.

[neolit123]

looking at TaskManager while FD compiles - it calls fdbuild.exe then it leaves a java.exe (some sort of IPC scheme here, i assume), while exiting fdbuild.exe. but unlike starting ASCSH and using the shell from console, the java.exe that FD instantiates does not lock the source files.

[elsassph]

I notice FD's version isn't up to date: https://github.com/elsassph/ascsh

You possibly want to compare them.

[elsassph]

Yes that's IPC. The Java process is maintained by FlashDevelop.exe.

[neolit123]

I notice FD's version isn't up to date: https://github.com/elsassph/ascsh

You possibly want to compare them.

just tried it - the same issue occurs.

[elsassph]

Then the difference may be the Java runtime, or the arguments...

[neolit123]

that java.exe process is versioned as follows for both ASCSH standalone and FD:
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

also tried the exact same arguments that mxmlc-cli from FD uses in ASCSH and the issue still happens.

[id-ilych]

I have similar issue: files that have errors in them kept locked preventing me from deleting/renaming them. Though I still able to edit/save them.
FlashDevelop 5.0.1.3
Java 1.8.0_45
ascsdk 17
Windows 8.1

[jcward]

Hmm, as an aside, I don't have this problem using ascshd from the commandline in Linux, though that's a obviously different environment.