Reserved filenames for FujiNet internal usage

[+x=usr(1536)]

Has any consideration been given to having certain filenames reserved for FujiNet-specific functions?

 

This actually goes back to the idea of being able to provide a list of what are effectively hyperlinked FujiNet servers directly-accessible from any FujiNet server.  My thought was that a reserved filename such as 'links' or 'Other Servers' could be created that would essentially be a placeholder for a flatfile containing all of the linked servers.  FujiNet would parse and display the contents of that file as a list of selectable links, either with or without the leading '+' to denote them as such.

 

Good, bad, indifferent?  I'm totally open to suggestions.

[tschak909]

looks cool at first glance  Following.

 

-Thom

 

[mozzwald]

What about using file extensions? .FNL could be a FujiNet Links file and you could organize them into multiple files, for example by country: usa.fnl, poland.fnl, germany.fnl, etc.

[+x=usr(1536)]

39 minutes ago, mozzwald said:

What about using file extensions? .FNL could be a FujiNet Links file and you could organize them into multiple files, for example by country: usa.fnl, poland.fnl, germany.fnl, etc.

Well...  That's not a bad idea at all   Gonna chew on that a bit; there's a lot of potential surrounding that approach.

 

As an adjunct: right now, selecting a FujiNet link loads the server name into host list slot 8.  This is a permanent change, at least in the sense that it overwrites whatever happens to be in that slot and remains persistent.

 

I tend to view those slots as being analogous to bookmarks - in other words, I don't expect them to change unless I change them myself.  Proposed change to that behaviour: just follow the link without changing what's in any host list slot.  If the user wants to bookmark a particular server, have an option bound to one of the keys to do so when a link is selected.

 

Thinking about it, this could open up the possibility of keeping the standard host slots as speed dials, with an actual local bookmarks file available for reference.  Hmm.

[mozzwald]

24 minutes ago, x=usr(1536) said:

I tend to view those slots as being analogous to bookmarks - in other words, I don't expect them to change unless I change them myself

I agree, but in the current firmware a mounted disk slot needs a host slot associated with it. Would need to come up with a different way to reference a host slot to a link.

 

I just realized that if you mount disk 1 from a link which overwrites host slot 8, then try to mount from a different link to disk 2 you've broken disk 1 since it probably doesn't exists on the 2nd linked server, yikes

[+x=usr(1536)]

10 minutes ago, mozzwald said:

I agree, but in the current firmware a mounted disk slot needs a host slot associated with it. Would need to come up with a different way to reference a host slot to a link.

So, in the idea that I'm suggesting, disk slots would remain untouched.  Only host slot behaviour would change.

 

About the best idea I have on this is a virtual / in-memory slot that's just the current working hostname.  Unless it's added to one of the existing host slots (or potential bookmark file), it's only used for the current session and has no persistence.  In practice, this would always be the most recently browsed-to server link, and is the same one that the disk slots would refer to.

 

Basically, it would be host slot 9 (or equivalent), and host slot 9 would remain invisible to the end user

10 minutes ago, mozzwald said:

I just realized that if you mount disk 1 from a link which overwrites host slot 8, then try to mount from a different link to disk 2 you've broken disk 1 since it probably doesn't exists on the 2nd linked server, yikes

Ooooh...  Good point.

[mozzwald]

1 minute ago, x=usr(1536) said:

Sorry - I didn't mean to refer to disk slots, only host slots.  Disk slots would remain untouched; only host slot behaviour would change.

The way firmware works now, a mounted disk always has a host slot associated to it. This is how the firmware references what hostname to get the disk image from. Implementing this is going to take some thought.

[+x=usr(1536)]

13 minutes ago, mozzwald said:

The way firmware works now, a mounted disk always has a host slot associated to it. This is how the firmware references what hostname to get the disk image from. Implementing this is going to take some thought.

Ah, ok.  Understood, and thanks for the clarification.