You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "scholarsmate (via GitHub)" <gi...@apache.org> on 2023/04/06 18:11:49 UTC
[GitHub] [daffodil-vscode] scholarsmate opened a new issue, #576: Handle changes made to an edited file done outside the editor instance
scholarsmate opened a new issue, #576:
URL: https://github.com/apache/daffodil-vscode/issues/576
If changes are made to the file being edited, clear the changes and reset the editor to the new file contents if the file still exists, or close the editor otherwise.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] scholarsmate commented on issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "scholarsmate (via GitHub)" <gi...@apache.org>.
scholarsmate commented on issue #576:
URL: https://github.com/apache/daffodil-vscode/issues/576#issuecomment-1515394921
@lrbarber, yes. The issue is that the changes are done with respect to the file in disk at the time the session is started. If for some reason that file changes outside of the session, the in-flight edits are invalid and disposed of.
There may be a way around it, like squirrel a copy of the file being edited away so that we have some recovery options available if the original file changes outside of a session.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] lrbarber commented on issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "lrbarber (via GitHub)" <gi...@apache.org>.
lrbarber commented on issue #576:
URL: https://github.com/apache/daffodil-vscode/issues/576#issuecomment-1515402735
As a user, I would not want my changes to disappear if someone else changes the base file! There **must** be a way to allow me to save my changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] stricklandrbls closed issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "stricklandrbls (via GitHub)" <gi...@apache.org>.
stricklandrbls closed issue #576: Handle changes made to an edited file done outside the editor instance
URL: https://github.com/apache/daffodil-vscode/issues/576
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] mbeckerle commented on issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "mbeckerle (via GitHub)" <gi...@apache.org>.
mbeckerle commented on issue #576:
URL: https://github.com/apache/daffodil-vscode/issues/576#issuecomment-1526012802
One alternative is locking the file somehow so concurrent edits aren't allowed at the system level.
(e.g., see https://www.baeldung.com/linux/file-locking)
To me that's very preferable to blindly copying the file. I can always do the copy myself. There is complexity to this having to do with avoiding leaving things locked in presence of failures, etc.
Detecting a concurrent edit dynamically (every time omegaEdit touches the file, verify that modify time has not changed first, and if it has offering options) and then offering to save to a different location is another approach. That enables lazy copying, which is again very preferable to proactive copying overhead.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] scholarsmate commented on issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "scholarsmate (via GitHub)" <gi...@apache.org>.
scholarsmate commented on issue #576:
URL: https://github.com/apache/daffodil-vscode/issues/576#issuecomment-1525886707
@lrbarber, yeah, losing your edits is not ideal. I've added code to Ωedit (https://github.com/ctc-oss/omega-edit/commit/c3b168f513b753177d81b0e3c61ac69549668657) that will deal with out-of-band file changes. The summary is that the original file is first copied to checkpoint directory and that is used to preserve the editing model through the lifetime of the session. The downside is that session creation will take more time because session creation will now include copying the original file (which _could_ be huge), and of course that's going to use temporary storage space. The application layer (e.g., the Data Editor) will need to find out from the user what they want to do in the case that the file being edited has been changed by some other process, and then handle it accordingly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] stricklandrbls closed issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "stricklandrbls (via GitHub)" <gi...@apache.org>.
stricklandrbls closed issue #576: Handle changes made to an edited file done outside the editor instance
URL: https://github.com/apache/daffodil-vscode/issues/576
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] lrbarber commented on issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "lrbarber (via GitHub)" <gi...@apache.org>.
lrbarber commented on issue #576:
URL: https://github.com/apache/daffodil-vscode/issues/576#issuecomment-1505973540
Does this issue really propose to remove all my edits if someone else changes the original file on disk?!
Perhaps it should merely give a notice and/or block `file save` and force the use of `save as`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [daffodil-vscode] scholarsmate commented on issue #576: Handle changes made to an edited file done outside the editor instance
Posted by "scholarsmate (via GitHub)" <gi...@apache.org>.
scholarsmate commented on issue #576:
URL: https://github.com/apache/daffodil-vscode/issues/576#issuecomment-1526167578
@mbeckerle, file locking is not going to be a viable solution. It's not reliable under Linux, and we have to also make it work under macOS and Windows. I tried using C++17 locks, and they work inside the same (multi-threaded) process or among cooperating process, but I can't recall a single time that I fired up vi, emacs, pico, nano or any other editor and have it deny a write to any file to which I had read/write permissions to and sufficient storage. I use both JetBrains IDEs and VS Code, often on the same files. JetBrains immediately applies all writes to the file and VS Code applies edits in memory and commits them on Save. VS Code uses Node.js's fs.watch which detects file changes and handles them by sync'ing the contents with what's on storage as long as you don't have changes in flight. With VS Code if you have changes in flight, it will not sync with changes in storage, and then once you try to save you'll get this message:
<img width="578" alt="Screenshot 2023-04-27 at 13 51 25" src="https://user-images.githubusercontent.com/2205472/234950635-5b4230d2-cfaa-414b-ad44-ebbf06158f08.png">
Allowing the user to reconcile the differences. These IDEs also don't have any file locking going on as far as I can tell using black-box testing.
By contrast, Ωedit doesn't keep any of the file content in memory, instead it tracks all changes and creates a memory efficient mathematical model of the edits such that when a request for any segment of the file is made and it calculates the current state of that segment on the fly, splicing it together with byte segments read from the original file (this is what makes Ωedit unique). If the original file is modified out-of-band, then the model collapses and I have no safe choice but to abandon the in-flight edits. This is the trade-off that Ωedit makes to enable it to handle files that most editors cannot handle because most editors load all the content into memory.
Now to cover the proactive "blind" copy. If an out-of-band change is made to the original file, it is too late for Ωedit to do anything about it because Ωedit does not have the file content in memory. There are no reasonable recovery options at this point, so the only thing that is safe to do is drop the in-flight changes and start again on the changed file. Some operating systems support block-level copy-on-write (COW) that make file copies very efficient (e.g., Brtfs, QNX, ZFS) which is great of Ωedit, but worse case a byte-for-byte copy is made. This copy method is simple, effective, and cross-platform (C++17's filesystem support for the win).
Ωedit also supports checkpoints in general, so this is an extension of its existing capabilities. This means that a checkpoint file is created with the in-flight changes applied, then that "frame" of edits are pushed onto a stack and a new active frame is created against the checkpointed file. This is what enables Ωedit to handle massive changes throughout the file in a memory efficient way, by checkpointing, run the massive algorithm (e.g., {down,up}-casing, bit-shifting, etc) streaming against the checkpoint file to a new temp file, then overwriting the checkpoint file with the algorithm-modified file, push that frame of edits onto a stack, then create a new edit frame against the checkpoint file. Solving the out-of-band changes means that we just checkpoint the original file at session creation time and we're good to go. There is a lot of careful book keeping involved Ωedit (lots of graph paper and automated testing for the win), but for the user, it means that we can und
o/redo massive changes to large files while being memory efficient (trade-off being more storage space).
I hope that makes sense. You can learn more about the editing model here: https://github.com/ctc-oss/omega-edit/wiki.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org