Nativescript-cli: Potential Build data corruption

[NathanaelA]

I have noticed with v2.4.0, that several times after I have freshly installed the Android platform (or on a new project), and then do a tns run android that the APK that it builds is corrupt.

This ONLY occurs on a new app/platform install where it has to copy all the JS from node_modules into the platform/android/... folder. One of the node_modules JS files, will end up being 0k in the platforms/android folder. Once I manually copy the file (like in this last case, application.android.js into the proper platform folder as application.js and then do another tns run android I'm up and running.

Please note the files in the node_modules are all correct and not corrupt; only a single one of the files that was copied by TNS over into the platforms/android/src/main/assets/app/tns_modules are corrupted. And the weird thing is it so far has only been ONE file that gets corrupted at a time. The rest of the files that are copied are all fine.

I can't tell you why it does it, but it has happened to me now a handful of times...

Node 6.9.1, TNS 2.4.0.

[tzraikov]

@NathanaelA We have not observed this behavior. Is this happening on a Windows PC? Can you confirm that this issue appears when using the @next version.

[NathanaelA]

@tzraikov - that is good to hear that it isn't widespread, and yes it is Windows 7 -- I'll try installing @next and see if it helps.

[NathanaelA]

I did three tests with @next and I don't see any 0k files. Yay! I'll keep you posted if it shows up again. Lets keep this bug open for another week; I create lots of sample projects over a week; so by the end of next week I should know if this was only present in 2.4.0.

[NathanaelA]

@tzraikov - I have some bad news. It just did it again to me. ;-(
I needed to see if an older plugin worked on 2.4, so I did:

tns platform remove android
tns platform add android@latest
npm install tns-core-master@latest --save
tns run android

In this case my "file-system-access.js" (android)

| Component        │ Current version       │ Latest version │ Information   │
│ nativescript     │ 2.5.0-2016-11-30-7269 │ 2.4.1          │ Up to date    │
│ tns-core-modules │ 2.4.1                 │ 2.4.1          │ Up to date    │
│ tns-android      │ 2.4.1                 │ 2.4.1          │ Up to date    │
│ tns-ios          │                       │ 2.4.0          │ Not installed │

[tzraikov]

@NathanaelA Thanks for the update. We will need some further information in order to investigate in detail. Please, could you do the following:

• try to reproduce the issue on a new project with --log trace option enabled
• send us the log
• send us the project in a state when the error occurred (including the platforms folder).

[NathanaelA]

Ok, I've tracked down this issue to what I believe is causing the problem.

I use Comodo Firewall; the virus scanning component (even though it isn't active) appears to be opening up every file and adding an ADS stream to it; so what is happening is in the
project-files-manager.js -> processPlatformSpecificFilesCore you copy the text into a file then immediately rename the file (eliminating the .ios. or .android. ). The copy into the file triggers the virus checker to open the file, the rename then occurs and depending on the timing the resulting file might be zero k. This seems to only occur if the drive is busy with something else; so it is really a very rare but random occurance, typically 1 file out of all of them).

To fix, I just needed to add something to "slow" down the write then rename, so I added a stat call into the routine and it appears to be allowing the stupid comodo virus scanner to create & close the ads stream properly, before the rename occurs.

According to Comodo forums, Comodo 8 does this, 10 supposedly doesn't do ADS streams anymore. So I'm going to try and upgrade later and see if this also fixes it, without adding a stat call into the mix.

Even though a stat call slows it down very slightly; it might still be worth you guys looking at doing this so that if any other people using Comodo 8 use NS, they won't get random corrupted files when you have that quick write->rename hit.

[rosen-vladimirov]

Hey @NathanaelA , great investigation. It's really strange that this happens, I've not used Comodo Firewall. We'll have to investigate possible fixes for this as adding just a stat that is not usable for anything else will seem awkward. I'm waiting for information if the issue is reproducible with Comodo 10, hopefully it will work fine.
We may try different approach for renaming the files, but lets see if Comodo 10 fixes the issue.
Btw have you tried using different Node.js version, it might be related as well.

[NathanaelA]

It was a lot of fun tracking it down. I'm a really good debugger (at my last "real" job, that was the skill they bonused me the most for, I can debug anything. :-D ) The issue had finally gotten so annoying and you guys hadn't seen it so I decided it had to be some interaction on my machine -- so I decided to use several hours to track it down. ;-) It was a lot of work, but I'm fairly certain based on some really low level tools what the issue is.

Since this issue has started a while back, I've replaced node a couple times. I actually upgraded from the 4's to 6's fairly recently. The issue is a real corner case; the write occurs, comodo picks it up & opens the file up to write to the ads stream, you rename it and comodo still has the file open. Technically any virus checker could cause this issue if they use ads streams to write info into (which most don't so it isn't something you need to worry about.);

As for using a stat call to slow it slightly down, yeah having a stat call there does seem counter productive, since the results aren't needed. All though you could add code to see if the file is 0k and display a warning since none of the .ios. or .android. files should be 0k... This could be a useful error for people who just forgot to do something for a platform and left the file empty.

I plan on upgrading to Comodo 10 in the next day or so and hopefully this will fix it for good. ;-)

[Plamen5kov]

@NathanaelA did updating to Comodo 10 fix the issues you were facing?

[NathanaelA]

@Plamen5kov - Yes, I have not seen this corruption since upgrading to v10 of the Comodo Firewall software. So this appears to be only an issue with the older Comodo software.