Re: [Hx] Folders and Do[c]uments

3 views
Skip to first unread message

Michael S. Scaramella, Esq. MSS@ScaraHoof.com

unread,
Aug 4, 2022, 2:32:51 PMAug 4
to Helix-L Discussion List
Tony,

Helix management of externally stored documents has been obsolete for years because only Classic macOS pathnames are supported. It is technically possible with consistent exercise of great care to avoid creating any pathnames that exceed the limits of Classic, but doing so is very error prone and greatly limits what our Unix-based computers are now capable of. Using Helix external document management is not at all recommendable unless and until Helix is upgraded to support contemporary macOS file storage. This major Helix disability has left the Document Management Main Feature Set of our commercial Helix-based applications nearly useless for many years.

Regards,

Michael

On Aug 4, 2022, at 11:40 AM, Anton a...@sommer-equity.de <Hel...@gibhenry.com> wrote:

…My question is, if I declare „always external“ in Helix, the pathname will be stored. That is, how I want it. However:   Should a NAS-drive needed to be replaced, I must be absolutely sure, the new drive will have exactly [t]he same path-name. What would be needed to make sure this is so?

regards
Tony Sommer

<+>-=-<+>-=-<+>-=-<+>-=-<+>-=-<+>-=-<+>

SCARAMELLA & HOOFNAGLE
Computer Division
 ~  *  ~

<+>-=-<+>-=-<+>-=-<+>-=-<+>-=-<+>-=-<+>

Greg Morin greg.morin@seachem.com

unread,
Aug 4, 2022, 4:47:18 PMAug 4
to Helix-L Discussion List
What are these issues Michael? We've been using external document storage with OS X flavors of Helix for over 10 years now with no issues. Well, no major issues. Helix seems to somehow magically embed in the external document info data about what user credentials were used for a file server when the document is stored to the file server. You only see the path when examining things, but somehow it "knows" User A is the one that connected to the file server. It's only an issue if the file server is not already mounted and User B is asked to enter credentials for User A to mount the server and retrieve the document. But the user can put in their own credentials and if they have the same permissions it mounts and they can access it as the paths are the same. It's just annoying that OS X doesn't auto-open for User B using their credentials for the file server from the keychain.

The other annoying issue is that I have a routine that reads in the filename and then renames it. I have to grab the file extension too to rename it properly. But if the total length of the file+extension exceeds 32 characters then it just truncates the end off and I lose my file extension. Oddly enough it used to work fine in Helix 6 under OS X I think but somewhere around Helix 7 it broke... but maybe it was 5 to 6, been so long I'm not sure... anyway Helix 6 used do something where it read the whole thing but clipped characters in the middle so I still got my file extension... since I was changing the file name I didn' really care about the old file name anyway, but I had to read the whole thing to get the extension at the end. Anyway, the work around now is I have a script that shortens the file names to 32 characters max then I load stuff in. (they are loaded in batches) Not ideal, but it's a relatively trivial work around

Greg Morin

Michael S. Scaramella, Esq. MSS@ScaraHoof.com

unread,
Aug 5, 2022, 3:31:00 PMAug 5
to Helix-L Discussion List
Greg,

Since Helix is still using ancient Classic storage APIs, the entirety of the pathname must be Classic-compatible to avoid problems. If referenced externally stored files are on shared storage volumes, then the name of the servers, the names of all volumes and folders in the hierarchies leading to the referenced files, and the names of the files themselves, all have to be Classic-compatible. This is very difficult to maintain on a file server running any version of macOS. We tried this for several years after the initial release of macOS. Validation of pathnames for Classic compatibility is quite complicated, involving many layers of cascading Locate, Extract, and Length tiles. Even if this validation is done, it only controls entry or editing of Document references within Helix Collections. Because applications other than Helix can change pathnames of files, it is necessary to periodically run the Helix Update Documents commands to find and manually repair broken document references stored in Helix Collections. We had expected that Helix would be updated to support macOS storage, but are still waiting for an update. Eventually, we decided that the disadvantages and work of manually maintaining Classic compatibility of storage exceeded the benefit of continuing to use our Document Management Main Feature Set, so we stopped.

Tony referenced the possibility of needing to replace storage hardware. When this is done problems can be revealed that were previously unnoticed. The ancient Classic storage APIs used by Helix should not be used with APFS storage according to Apple, which leaves HFS or WFS+ formats as options. When storage formatted this way is used by macOS, long names of files and folders are shortened by substituting part of the long name with a random string. Normally this is not seen by users. Helix only knows to store these shortened names. As a result, unless Classic compatibility is strictly maintained, only bit-for-bit duplication of storage devices can maintain the accuracy of Helix document references.

These Helix Document Management problems and disabilities are far beyond trivial. Tony wrote: “I want to provide my kids with a reliable way to find old documents.” Sadly, in its current obsolete state, Helix Document Management cannot really fulfill that need.

Regards,

Michael
Reply all
Reply to author
Forward
0 new messages