File locking interaction between Bracket and SimpLESS

[nxame]

I am using SimpLESS to compile my LESS CSS and Bracket is the editor to work. While saving the LESS file very often (mean while the LESS file is being watched by SimpLESS, in background) - I get security error (See image for error

).

Steps to repro:
a.) Create a LESS file
b.) Open it in Bracket
c.) Drag this LESS file over SimpLESS to watch (so that it will compile the LESS in to CSS file and you use it in page)
d.) Now write some styles in the LESS file - in Bracket. Do write few class, change a property save it. Again change a property - save it. Now you will see the same error.

Very few times it wont show the error while saving often - else it will show up. Wait for few mins or close Bracket & SimpLESS to fix that error.

[peterflynn]

@shekhardesigner do you see the same problem with any other editor? For example, if you save changes twice rapidly in Notepad?

[njx]

Reviewed. To me for investigation in Sprint 20, to see what's going on and investigate possible workarounds.

[njx]

I can repro on Windows easily--the errors pop up often, though not every single time. After dragging the project folder to SimpLESS, I often get errors when trying to open the LESS file; if I do manage to open it (which I can sometimes do after rebooting Brackets), I often get errors when trying to save it. Other text editors don't appear to have this problem, so it's something about the way we're accessing the files.

[njx]

It looks like setting our ReadFile/WriteFile APIs to set FILE_SHARE_READ "fixes" the problem. However, it's not clear why we happen to collide with SimpLESS so often. Looking at its source code (it's written in Titanium), it seems like it polls timestamps once a second. That's not that often, and (reading down into the Titanium source code) it seems like getting a timestamp just uses GetFileAttributesEx(); I would be surprised if that actually locks the file. So it's a bit of a mystery as to why the error happens so frequently.

The other issue with just setting FILE_SHARE_READ is that if we're actually writing the file, then it's conceivable that SimpLESS could get a half-written copy. This is basically #881.

We might want to consider waiting till we switch to Node for filesystem support to deal with this. On the other hand, it might be worth putting in a quick fix since this is pretty terrible once it starts happening. The danger is that an incomplete file might get read by SimpLESS.

I'm currently checking to see if other things that watch files (e.g. yeoman) have the same issue.

[njx]

See also #2683, which isn't directly related to this bug but causes workflow issues when using external watchers like SimpLESS.

[njx]

FYI, this doesn't seem to be an issue on Mac.

[njx]

This was fixed via adobe/brackets-shell#195. @shekhardesigner, please check this in the Sprint 20 build when it comes out in a couple of weeks. Thanks!

[nxame]

Many thanks!