It's not really a locking system like you describe. Instead, it basically works by comparing the contents of the data that was saved last time to what it reads off of the disk. If it doesn't match what it expects, an error is reported. It uses hashing to make this take less memory, but that doesn't make that much of a difference besides reducing memory consumption.
My suggested route for recovery if an error is reported there is to attempt to save again. It will fall back to the download saver and you will have to merge the two versions manually using tiddler import/export. I've uploaded a YouTube video demonstrating how the check works. Note that since the plugin only cares about contents, the wiki needs to be non-identical (usually happens immediately due to modification timestamps). https://youtu.be/F6HZo1e-5k8 It would definitely be possible to store a session fingerprint in local storage or IndexedDB to check for issues locally. However, that doesn't prevent issues with concurrent modifications from different browsers or on different computers via network drives. On Tuesday, February 22, 2022 at 7:47:20 PM UTC-8 TW Tones wrote: > Dylon, > > *One of the reasons for introducing the save button at startup is so the > plugin can quickly read the original file and compute its file hash as soon > as possible.* > > In some of my own experiments, in a startup action if the wiki is > available for editing I immediately save and reload it to indicate this > session "owns it". Similarly when finished the final save needs to release > it. > > - With a splash screen advising its loading this may be ok because in > need only be done once per session (that has the wiki for edit/save) even > on larger wikis. > > > I have come across two issues; > > - The browser session needs a finger print to be saved in local > storage, so this can be compared with the loaded copy of the wiki to check > ownership > - I have found an almost unique fingerprint > - If the wiki is on file:// I have not found how to get a seperate > finger print for each tab, so it could be opened in more than one tab and > save will only save the current tabs changes. > > Have you found a way to open a file:// wiki in two tabs and not confuse > the session? > > On Wednesday, 23 February 2022 at 13:09:32 UTC+11 dyllon...@gmail.com > wrote: > >> For contention, the current version actually does provide some integrity >> measures. One of the reasons for introducing the save button at startup is >> so the plugin can quickly read the original file and compute its file hash >> as soon as possible. >> >> One the first save (i.e. when you click the button on the launch modal), >> the hash of the serialized wiki is recorded. On subsequent saves, the >> plugin compares the hash of the new version to the hash of the old version >> to see if the file has changed unexpectedly (i.e. changes were made in a >> different browser pane or it is on a network drive and someone else changed >> it). >> >> I'm hesitant to rely too much on Tiddlywiki internals to try and maintain >> forward compatibility, but it would be nice if this check were possible >> without triggering an actual save. The other reason is to avoid unexpected >> prompts when autosaving things obviously. >> >> I will also admit that as a software developer, I'm not the best person >> at making people understand the saving mechanism without overwhelming them >> with technical details. >> >> As for using a more intuitive save button, I'm welcome to suggestions >> and/or pull requests so long as things scale for different browser/wiki >> layouts and it doesn't pull in any large images (an SVG or something would >> probably be ok). I agree the button used right now is kind of ugly. Another >> thing to keep in mind with suggestions is that people might be using >> different color schemes which I'd like the plugin to try and respect. >> >> Thanks for your feedback! >> >> On Friday, February 18, 2022 at 5:13:26 PM UTC-8 TW Tones wrote: >> >>> Folks, >>> >>> I believe this is already available on tiddlywiki.com at >>> https://tiddlywiki.com/#Saving%20on%20Browser%20with%20File%20System%20Access%20API >>> >>> It is not yet comprehensively documented and it is hard for me to >>> determine what level of functionality and customisation is available to us. >>> As a solution only on Chromium browsers it is not yet global in >>> application, so understanding its value is even harder to determine. >>> >>> I also ask myself "We require a click event to start the save dialogue" >>> if this could not be placed in a save button "lookalike" or another way to >>> make it user friendly. Ie just in time, not startup, Although in this >>> thread others suggest they do not need it. >>> >>> Can someone write a user designer perspective and/or comparison with >>> existing methods? >>> >>> My concerns; >>> >>> - How to design online tiddlywikis with a non-intrusive saving >>> mechanism users can understand. >>> - Dealing with the contention possible with two parties editing the >>> same site. >>> >>> I would appreciate it is someone can spell this out a little more for us >>> who need it, and can't easily understand this from the jargon and reading >>> between the lines in this discussion. >>> >>> Thanks >>> Tones >>> On Wednesday, 9 February 2022 at 11:10:40 UTC+11 PMario wrote: >>> >>>> Hi, >>>> I do like that option. >>>> -mario >>>> >>>> On Wednesday, February 9, 2022 at 12:11:06 AM UTC+1 dyllon...@gmail.com >>>> wrote: >>>> >>>>> It does work, though I think it is disruptive asking as soon as >>>>> something is done which triggers autosave. However, I have put in an >>>>> option >>>>> with version 0.7.1 to disable the modal for those who don't like it. >>>>> >>>>> On Sunday, February 6, 2022 at 1:46:16 AM UTC-8 PMario wrote: >>>>> >>>>>> On Sunday, February 6, 2022 at 12:54:25 AM UTC+1 brian....@gmail.com >>>>>> wrote: >>>>>> ... >>>>>> >>>>>>> Now with the indexdb entry re-populated, the sequence looks like >>>>>>> this: >>>>>>> >>>>>>> 1. Reload the TW page >>>>>>> 2. Click the + button to create a new tiddler >>>>>>> 3. Click the checkmark to save the tiddler >>>>>>> 4. A dialog box asks me if I want to let the site edit the file. >>>>>>> I click the "edit file" button >>>>>>> 5. The file saves >>>>>>> >>>>>>> So it is working for me even without the settings modal. Do you see >>>>>>> this same behavior? >>>>>>> >>>>>> >>>>>> I also think the modal isn't needed. The API requires user >>>>>> interaction. ... But I think the described behaviour is good. The >>>>>> permission is requested, when the first save happens. Since this save is >>>>>> a >>>>>> user interaction it should be good enough. >>>>>> >>>>>> -mario >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/f500692b-f817-4b93-bc1c-11cb85a7cfc7n%40googlegroups.com.
