Files in a Watched folder - how does it all work?

Q & A - getting started with Tinderbox
1

WRT " File ▸ Watch ▸ Folder from Finder…"
the Tbx Help states “Changes made in Tinderbox are not forwarded to the application.”

Which means that any changes to $Attributes or $Attribute Values may be performed, as long as the $Prototype Value of “Imported From Finder” is retained? Or is that $Prototype Value not a requirement?

And if one enters any text in the $Text field of such a watched note - is the connection between that Note and the source Finder note broken? Or do subsequent changes in the source file overwrite any alterations to the $Text from within Tbx?

Just trying to understand the cans and don’ts.

2

When I wrote that I meant “…are not forwarded to the [source] application.” (i.e. in this case Finder). The point being made was that in Tinderbox watches [source app] but [source app] doesn’t watch Tinderbox.

Tinderbox ‘watching’ mirrors external source(s) for the documenting sources, in a one-way manner: it imports but does not export data… If you want to edit the generated note, it is better to copy it to a location outside the watched folder. Otherwise a refresh of the watch process may overwrite local changes. This is why I say ‘mirror’ not ‘sync’. Tinderbox makes a note to show values found outside the Tinderbox app. It is not a two-way sync.

Is the latter the confusion or is it a different aspect of the process?I ask less I update the relevant notes incorrectly. :slight_smile:

1 Like
3

A different part - basically trying to understand how Tbx deals with a Watched Note vis-avis any local created Note. The Watched Note, as I understand it, is allocated a $Prototype - therefore specific Attributes may be applied to this Note, but you shouldn’t edit the $Text or else….? What happens? Does the Note you have modified now break away from its Finder incarnation, or will it simply be reverted when you relaunch that project?

4

I found this in the archive:

https://forum.eastgate.com/t/notes-from-a-watched-folder/2719
Which indicates that any changes to $Attributes etc. are over-written on the ‘next pass’ (ie., when the Tbx project is relaunched).

And I also discovered this gem, which is a variation on what I’m playing around with rn:
https://forum.eastgate.com/t/zettelkasten-with-tinderbox-and-the-archive/3551

Hope some of this provokes a conversation at the next meetup :slight_smile:

5

But, you can’t change attributes as the watch-created notes use a prototype that sets $ReadOnly (q.v. as well as Non-editable notes).

So, ‘watched’ notes are like an external non-editable alias to an external resource: a one way view on to some external text. Think of it as being akin to an agent. If the queried source changes, new aliases (watched notes) overwriting the existing one and showing the current state of the external resource. The only 3 attributes of real note, apart from those accounting the watch process, are $Name, $Text, and $Tags. Whether the watched note is recreated or updated is actually moot because all three are read-only. Tinderbox’s own Help is, I think, unintentionally misleading here by stating:

The imported notes inherit from a built-in prototype named “Imported From Finder,” allowing you to set common displayed attributes or visual appearance.

As the watched notes’ prototype sets $ReadOnly—and which it must be presumed the user should not disable, that whilst $DisplayedAttributes can be altered neither the Displayed Attributes table nor Get Info pop-up can be used to edit those attributes.

The clear implication is that watched notes are literally to be read only. If you wish to use the notes’ data in a normal note, the data must first be moved/copied out of the watched notes’ container in the TBX. Remember this is a watch feature not a sync feature.

If copying the watched note elsewhere in your TBX, ensure you remove the “Imported from Finder” prototype. You might also think to alter the note’s $Name, e.g. by removing the file extension that the watched folder note adds by default. IOW, a watched folder note “agenda.tbx” might get copied elsewhere and renamed “Agenda”†.

If your next question is how do I keep those two notes’ $Text reconciled, I think that’s a a separate question/thread.

Remember that, however much one may wish otherwise: watch != sync.

†. If you are going to keep the same $Name, I strongly suggest your watched folder goes at the end of the root outline. this places the duplicate-named notes last by $OutlineOrder. Recall that when expecting to match one item

1 Like
6

Tinderbox was confused by some unusual text encodings used in these files. The next backstage release (b571) will recognize a wider range of text encodings.

1 Like
7

Ah, thanks much @mwra! This is exactly what I was trying to get a handle on.

As the watched notes’ prototype sets $ReadOnly—and which it must be presumed the user should not disable , that whilst $DisplayedAttributes can be altered neither the Displayed Attributes table nor Get Info pop-up can be used to edit those attributes.

This bit implies (and I tested it) that you CAN actually modify Attribute Values of $Attribute that is not on the $DisplayedAttributes list. Confirmed, and it doesn’t appear to “break” the source file or the connection in any way, which was my main concern.

So - working backwards - I am assuming that the Note in the Watch Folder is something like a sock or gauntlet of the actual source note, upon which Attributes can be hung and modified - except for the key fields of $Name, $Text, $Tags, and $ReadOnly, as you point out. Logically, one would also steer clear of $WatchFolder and $DisplayedAttributes.

The Watch vs. Sync issue is not really a concern. What I am trying to do is modify just ONE user Attribute value on the gauntlet so that Tinderbox can advise me which of the Watched Notes I’ve looked at from within Tinderbox, in terms with what action is pending on that note. Specifically, let’s say -

For a User Attribute = $Flagger
If source File has not been looked at, $Flagger == “”
If source File has been looked at in Tbx, $Flagger==“seen 09/21/2022 - add to Project Z”
If source File needs to be deleted in source Finder folder, $Flagger==“Delete Me, data obsolete”
and so on.

1 Like
8

Good to know!

Am already able to see html and Markdown. Recognition of YAML seems not to translate, but that could be me. CSVs work as text, which is fine for basic scans/searches. Also, Taskpaper (which is basically a kind of MD right?) works well.

Excel/xml would be awesome.

Additionally - if it’s possible to display - with format-specific icon/s - the non-readable file formats within the Watched Folder, that would be very useful and a time-saver.

9

Somme follow-up points from further testing.

In default condition, a watch-created note cannot be edited via Displayed Attributes table, Get Info or $Text pane. This makes sense due to the $ReadOnly flag being set true as inherited via the note’s prototype.

It appears that only $Text is updated for existing source files, but not $Tags (i.e. source Finder tags). I experimented with setting different colour tags on the files finder Get Info dialog. My hunch is this is because using Get Info doesn’t change the file modified date in the OS and Tinderbox uses the latter to detect changes. Sure enough, if the file is touched and the the modified date/time changes $Tags is re-read—so that clarifies that issue of what triggers update of an existing note.

Thus If a source note’s macOS modified date/time changes, the Tinderbox note will refresh and both existing $Text and $Tags with be overwritten with source data (i.e. $Tags data items aren’t merged).

The Tinderbox watched note’s $LastFetched date/time is misleading. It isn’t when the watch process last fired but when a change at source was last detected. (@eastgate is would be useful if the watched folder TBX container used $LastFetched to show when the watch process last ran—as opposed to if/when any individual note changed. That would answer “how up-to-date is the watched folder data?” which is not clear at present)

Attributes can be edited using QuickStamp or Action code (stamps, etc.) but—and this is hard to test and watch can’t be updated on-demand—it should be assumed that the next update will overwrite $Text or $Tags changes but other non-watch-related attribute values should be OK.

Also, whilst Tinderbox will make new notes in the watched-folder container for new files added in the watched folders, if a source file is removed the note in Tinderbox is not removed. This means the Tinderbox end of the process now has an orphan file incorrectly asserting the presence of a now missing file. (@eastgate is that expected behaviour? Might it be useful to indicate in some way the source is now missing - e.g. with a title strikethrouogh?)

The user can:

  • alter the prototype’s Displayed Attributes—this would be the easiest way for @archurh to add in his extra tracking attributes
  • as changes of source text (and in some cases finder tags) updates the note, whilst $Text (and sometimes $Tags) are overwritten other user data is not.
    • Thus if the user adds extra Displayed Attributes and populates other attributes (e.g. user attributes tracking actions taken) this data does persist [NOTE: tested in v9.3.0]
  • untick/toggle $ReadOnly in a watched note’s Displayed Attributes allowing attributes (Displayed Attributes or others) to be edited.
    • Tread carefully here as uncharted territory is what happens if Tinderbox updates the watched folder notes whilst selected/being edited by the user. It’s too easy to say (in one’s imagination) “that will never happen”.
1 Like
10

Would that work off file extensions, which in some cases are not indicative of intenal content type, or some other detector.

I wonder whether it might be easier to have an in-doc text list of file extensions considered case-insensitively as (likely),to contain useable textual/tabular contend e.g. txt;docx;rtf;csv . If a doc default were seeded to the doc settings, the user could update. But, for an edge feature like this the ROI of doing that seems tenuous. Better perhaps might be the user writes their own list and adds an edict to the prototype to test $Name values for membership of the ‘good’ list and mark others accordingly. Whether you set and icon for goo, bad or both is really up to the users own style.

1 Like
11

Tinderbox is reluctant to delete notes, but the question of notes in a watched folder that no longer have a corresponding file keeps coming up. I’ll look into either deleting those notes or setting $NameStrike.

1 Like
12

The caution makes sense, I’ll document the status quo. Done! See Finder watched folders.

As this is an inbound informative method than some 24/7 sync method, I think $NameStrike for missing/deleted source items makes sense, letting the user delete them if they so desire.

1 Like
13

Outstanding investigative work and conclusions, a perfect post :slight_smile:

14

Resource Forks <koff, hack> lol

1 Like
15

Elegant solution!