Overview

[Rahere]

Returning to TW after a break, I notice it still has ideosyncratic file-writing, what you're currently doing is backwards, as the result of lazy coding: MyFile, MyFile1...MyFileN. The headache you're causing is that there is no pointer to the current live file, so when a user reloads, he's reloading the outdated old copy. That's wrong, and was established as an incorrect protocol nigh on 50 years ago. I date back to the days when we were making fundamental decisions about the differentiation between instructions and data, in passing: my first coding was on the Lyons Leo, 20-column input cards (yes, that was before the 80-column ones, they had sprocket holes in the header strip).

The core logic is:

1. We have an existing file which is known to be "clean"

2. A copy is loaded, and the User changes something, making the live copy "dirty"

3. At that point, a set of choices are possible:

• Drop the dirty
• Keep working with the dirty
• Save the dirty

4. Presuming the first two are irrelevant loops, I'll focus on 3.

It's to be remembered that even the file index (directory, folder, whatever) is simply another file containing data about what's actually on disk somewhere: the name, the start point of the actual file, security settings, dates and times, etc etc etc.

Old and New in this case are just labels, representing some unlknown file name. New is likely to be a temporary system-assigned string, which is linguistically incoherent, just a set of random characters which isn't already a filename.

• While saving, for some microseconds the file copy is incomplete. Therefore, we don't want to overwrite Old (the Clean version) yet.
• Once the New file write is complete and checked, we then have 2 Clean versions on disk, Old and New.
• Old is RENAMEd in the Live copy of the index, not yet saved.
• New is RENAMEd to its definitive name in the same.
• Old may be deleted, if an archive history isn't being kept, returning its storage to the available pool. This is routine Operating System housekeeping.
• The Index is saved, committing everything.

Doing it this way, at no time is a clean copy absent from file.

[Eric Shulman]

On Tuesday, March 5, 2019 at 2:31:22 AM UTC-8, Rahere wrote:

Returning to TW after a break, I notice it still has ideosyncratic file-writing, what you're currently doing is backwards, as the result of lazy coding: MyFile, MyFile1...MyFileN. The headache you're causing is that there is no pointer to the current live file, so when a user reloads, he's reloading the outdated old copy. That's wrong, and was established as an incorrect protocol nigh on 50 years ago. I date back to the days when we were making fundamental decisions about the differentiation between instructions and data, in passing: my first coding was on the Lyons Leo, 20-column input cards (yes, that was before the 80-column ones, they had sprocket holes in the header strip).

The current situation is not due to "lazy coding".  A great deal of effort has been put into addressing the issues surrounding file-writing from TW.  What you have failed to recognize is that, because TW runs in a browser environment, it is VERY limited in the ways in which it can access the filesystem.

It's to be remembered that even the file index (directory, folder, whatever) is simply another file containing data about what's actually on disk somewhere: the name, the start point of the actual file, security settings, dates and times, etc etc etc.

It's ALSO to be remembered that modern browsers no longer permit direct, programmatic access to this information.  We cannot create folders, read "file index" information, rename files, etc., so the "simple" file saving logic you outline -- which, by the way, is already VERY well understood by Jeremy, myself, and many other TW core contributors -- CANNOT be implemented using browser-based handling alone.

By default, the only standard cross-platform compatible way to write a file is to use the browser's intrinsic "download a file" handling.  Depending upon how you have configured your browser (and which browser/platform you are using), you may or may not be prompted for the 'target' filename for the "download saving" process, and any automatic file numbering (e.g. index, index (1), index (2), etc.) is determined by the file system, NOT the TW application.

Note: there ARE several other file-saving solutions that have been implemented that DO provide better control over file naming while saving, but these solutions generally require installing either a custom browser addon, or some kind of "wrapper/launcher" app that embeds a browser within a platform-specific executable that provides code for handling the file I/O. 

-e

Eric Shulman

TiddlyTools.com: "Small Tools for Big Ideas!" (tm)

InsideTiddlyWiki: The Missing Manuals

P.S. By the way.... the first computer *I* programmed was a DEC PDP 8E via a KSR33 Teletype with *paper tape* punch/reader... and that was 42 years ago.

[TonyM]

Rahere,

Before offering a strong criticism of something you do not already know about in detail, ask questions first. Ask people to explain why it seems contrary to what you expect, then and only then and with humility put forward your criticism.

Your email simply looks like an uninformed, somewhat rude statement by someone who thinks too highly of their own knowledge.

Or perhaps something is lost in translation?

This is strong and capable software with powers beyond the normal and a happy community who works hard to solve sometimes complex issues. If you know so much, join the team and help make it be better.

Regards
Tony

[PMario]

Hi Rahere,

As Eric pointed out, _all_ browser vendors made it incredibly hard to directly access the users harddrive. Mainly because of security reasons. ...

Starting with FF57 (late 2017) we couldn't use TiddlyFox AddOn anymore, since the AddOn mechanism was completely changed in an incompatible way.

That's why I did create a different AddOn which is named file-backups. ... It allows TiddlyWiki5 _and_ TWclassic to save to the browser Downloads directory!.

See Downloads directory and Downloads directory + subfolders ONLY!. ... This is a restriction, which comes from the browser vendors and is not my idea ;)

The plugin also contains a backup strategy, that I like quite a bit. It is described here: https://pmario.github.io/file-backups/

IMO 1 image is worth a 1000 words. So have a look at 1000+ images ;) Watch the Video!

The latest AddOn version is 0.3.5 the video shows 0.2.1. But the mechanism is still the same.

have fun!

mario

PS - If you use it: Support it :)