What does inPlace do?

[kenchris]

In response to w3ctag/design-reviews#390

Also, I find inPlace confusing. It doesn't explain what inPlace does, and repeats the description of keepExistingData's behavior. Our understanding so far is that inPlace = true means it will write directly to the destination file without creating a temporary copy first, but it's not clear. So potentially faster, but I though the copy was there because of security and integrity - I understood you never wanted to write incomplete data.

[cynthia]

In particular, I'm curious whether or not inPlace would give some form of guarantee of exclusive access, since multiple tabs clobbering the same file seems like asking for trouble.

[mkruisselbrink]

I tried to make it bit clearer what inPlace is supposed to be in the documentation for createWriter. Although to be honest I'm not quite sure yet what inPlace=true is going to be like. It seems like we'll want to provide something like that, but it is rather unclear at this point how we will do that while not making it less secure. Because of that the current description of inPlace=true is kind of hand-wavy not really giving any guarantees (and rather giving a lack of guarantees), which makes the difference between it and inPlace=false less clear.

[foolip]

inPlace was removed in commit 5e1146e.

[pizzapanther]

I'm writing a text editor and notice the current implementation in Chrome breaks file watch processes. Since the file is replaced and not updated in place, the file watcher catches the first edit but not subsequent edits. This throws a wrench in development processes which watch files and automatically recompile. Here are example events I caught with inotify.

$ python3 -m pyinotify narf.txt
<Event dir=False mask=0x4 maskname=IN_ATTRIB name='' path=narf.txt pathname=/home/paul/tmp/narf.txt wd=1 >
<Event dir=False mask=0x400 maskname=IN_DELETE_SELF name='' path=narf.txt pathname=/home/paul/tmp/narf.txt wd=1 >
<Event dir=False mask=0x8000 maskname=IN_IGNORED name='' path=narf.txt pathname=/home/paul/tmp/narf.txt wd=1 >

Those are the events after the first edit. Edits after the first edit do not show up in the file watch. I think what is happening is the file is watched by file ID and not by path. Thus when the original file is deleted IN_DELETE_SELF the file watcher loses track of edits.

Since this method of editing files is not typical, it would be great to have an option to edit in place.