HI Pengju, savetiddlers uses the download mechanism. With firefox on linux if 2 downloads to the same file are attempted (that is another download to the same file is started before the first has finished) both will fail and the original file will have be lost, this is why the de-bounce was added. I do not have access to a mac so cannot test on the mac. I understand that you are using version 0.6. I cannot try and fix older version of the extension. If you can tell me the problem you have with current version I will investigate.
cheers BJ On Wednesday, July 24, 2019 at 6:37:05 AM UTC+2, Pengju Yan wrote: > > > > On Tuesday, July 23, 2019 at 3:15:44 PM UTC+8, Yakov wrote: >> >> Oh gosh, do you mean you had 2 subsequent saves with a little time gap >> between them? (could you describe your scenario so that I'm more aware of >> this potential problem? MainTiddlySaver hasn't debouncing implemented yet, >> but I never experienced this problem with content, only with options >> storage) If there's such problem, we should describe it in detail and refer >> to this in future development; I wasn't expecting anything like this in an >> extension saver (or may be the source of the problem is a bit different >> from what you describe?) We really need a reproducible scenario. >> > > Yes, exactly. I enabled both autosave and savebackups so that I don't need > to worry about any minor mistaken typings (you know we don't have a REDO > right?). My TWC file is of >6M size so saving takes seconds to finish. > savetidllers work like this way: When the user triggers a saving, it puts > file name in the "debouncing" dict and will remove it from the dict once > the saving finishes. But in several cases, it just doesn't removed my file > name from the "debouncing" dict and then all my subsequent savings will > just don't happen. I guess this problem will happen if I trigger successive > savings with just a very short time period in between, although I'm not > very sure. > > After several cases of catastrophic losses, I wrote a local crontab (macOS > launchctl) script to monitor my backup folders to check whether subsequent > backup files are of the same length (indicating that the main TWC file is > not successfully changed). That's how I survived before Timimi+TWC appeared. > > Seems like BJ is the developer of savetiddlers? I suggest the author takes > a serious look at this issue (if the author likes to maintain it in a long > term) and I'll help to discuss about the reproduction. > > Anyway, I don't think "debouncing" is necessary. It does not hurt even if > the user saves too frequently. So in my own (unsuccessful) modified > savetiddlers, I simply removed this mechanism (Though it doesn't not work > under FireFox 68.0.1). > > I don't think we need any documentation talking about this problem, > because it happens just within a specific saver. > > Yeah, I second this proposal (thinking about it for some time already), >> but this is a second level of IO improving which I'd address when a) I >> finish making TWC saving async and b) some documentation about >> IO/developing savers and editing (collaborating) workflow/infrastructure is >> established – because this is a more complicated idea and is less trivial >> to implement, especially when there's no docs describing it. >> >> Great. We can first make asynchronous saving work and then improves it. > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/651b87ee-6a10-4bb6-9c58-72355c8ae0cf%40googlegroups.com.
