FileMakerメディア ファイルパス【改】

FileMakerで作るメディア管理のファイルパスについての続編というか訂正・改訂編です。

何が起きたかというと、それまで気にせず通過していた己の理解不足に起因する問題が浮上しました。FileMakerの「パス」についてこれまで誤解に基づいて間違った処置をしていたことを知りました。

ぐだぐだ書いている投稿もあります → FileMakerのパスで苦しんだ話 これの続きっぽいお話になります。

何を間違っていたか

パス

パスはディレクトリを辿って目的地にたどり着ける記述です。コンピュータの世界に必ずあります。ファイルやフォルダを特定する正しい道筋であることに違いはありません。

パスに似たものにURLなんかがあります。https:// とか ftp:// とか、接頭語がついています。種類を特定するための文言でしょうか。https:// とあればまず人はそれをセキュリティ付きURLだと思います。接頭語にも、よく判らないながら絶対的な信頼があると思います。ftp:// とあればそれは絶対に FTP なんです。ftp:// が http:// や poopoo:// になったり、poopoo:// なのに「お客さん、これ、ほんとはFTPなんですよ」とはなりません。

FileMakerのパス

FileMakerにおけるパスはURLなんかと同じ接頭語付きのパスで、純粋なパスではないんですね。種類や用途を常に特定してきます。

純粋なパスはない

FileMakerにはディレクトリを辿りファイルやフォルダを特定するだけの普通のパスはありません。ここが重要です。

夢や幻覚に満ちた映画がありますね。普通の人はそういうややこしい映画を見ると「で、いろんな話が混ざり合ってるけど、ほんとの話はどれなの?」と、筋の通った本物の本編ストーリーを求めがちです。でも大抵の場合、そんなものはありません。それと同じです。

何が同じなんだか💦💦

FileMaker には、一本筋の通った「本物のパスの記述」というものはありません。ここが、長年誤解していた重要事項でした。

この誤解のせいで何が起きたかというと「ファイルパス」というフィールドを、唯一絶対的なパスの根幹として位置づけていました。「で、本当のパスはどれなの」というときの本当のパスが存在すると思ってしまったんです。

普通のパスというのはただ道しるべであって、そのファイルが画像であろうがPDFであろうがLivePicture書類であろうが体をないしていないゴミであろうが何だろうが、ファイルはフォルダではないという根幹は揺るぎませんし、場所を特定する以外の意味を加えたり変化させたりしません。この大局観が、パスの信頼です。

FileMakerのパスはそうではありません。接頭語との組み合わせ以外にパスは存在せず、目的地ファイルが画像であるのかムービーであるのか、元々どこにあったファイルなのか、FileMakerが対応しているタイプなのか、そういった小さな分類が根幹となります。経済学ではよくマクロとミクロとか言います。それと同じです。

何が同じなんだか💦💦

一般のパスでは /Voluems/Cage/boy.jpg とあれば、boy.jpg を特定できます。それ以外の意味は何もありません。画像かどうかなど知ったことではないんです。

FileMakerでは、例えば imagemac:/OneSSD/Cage/boy.jpg は boy.jpgという画像ファイルを特定できますが、file://OneSSD/Cage/boy.jpg だとパスを認識せずファイルとして特定できなくなります。

/fm-path.afphoto は画像ファイルですが、 file:/fm-path.afphoto になります。FileMakerが対応していない画像タイプだからです。FileMakerが対応していない画像タイプは、FileMakerにとって画像ではありません。画像かどうかではなく、FileMakerが対応しているかどうかが優先されます。 imagemac:/Users/user/fm-path.afphoto では機能しません。

FileMakerが扱うパスは、パス情報をオマケに持つものの、根幹はFileMaker事情のミクロ的な分類データであると言えます。

種類と目的+パスがセットになったFileMakerのパスは、普通のパスのように使えません。目的に応じて使い分けたり作り分ける必要があったんです。

弊害が表面化するのは「照合」

FileMaker が作るパスは常に接頭語付きのパスですから、それをパスとして特殊な用途、例えばリレーションの「照合」に使ったりしたら、いろいろ不整合が起きてしまいます。

テーブルをまたいだときに「image:」だの「imagemac:」だのとそれぞれバラバラだったら照合もくそもありませんし。

また、フォルダインポートで更新するときに「ファイルパス」を照合フィールドに指定してもまったく照合なんかしてくれません。

以前リレーション用に接頭語を取っ払った「パスモドキ」フィールドを作りましたが、あれこそ正しいやり方でした。

※ 追記: まだまだ少し正しくありませんでした。間違っているわけではないですが、照合での問題は根深い話でした -> FileMakerで正しくリレーションできない現象、原因と解決

FileMakerで取得できるパスのようなもの二点

種類+パス

GetAsTextで取得する分類情報にパスがくっついたもの。FileMakerで取得できるパスの形。FileMakerの都合による勝手な分類がなされて接頭語として付与されます。

普通のパスが欲しい場合、接頭語以降のパス部分を利用します。

インポート元パス

フォルダ一括インポートでアイテムを取得するときに「ファイルパス」と示され取得できるパス。実態は、その時点でどのファイルをインポートしたかの記録にすぎません。長年これを勘違いして「パス」であると思い込んだことが多くの悲劇を生みました。

インポート時に得られるパスの接頭語は「 file:// 」で、この書式は厳密にはFileMakerのパスですらありません。その証拠に、V19から採用されたパスの書式を変換する関数 ConvertFromFileMakerPath() で、パスとして認識されず何にも変換できません。

インポート時に取得できる「 file:// 」は、パスの体をなしていない単なるメモ書きと思っておくのが正解でした。

file:// 以降を抽出するともちろんパスです。そしてその後の操作によってはGetAsText のパスと異なってくる可能性がありますよね。インポート元パスとGetAsTextパスは一緒くたにしてはいけなかったのに、それをやってドツボにハマったというのが私の愚かなところでした。

FileMakerで取得できるパスのようなものは上記二点。FileMakerには「ほんとのパス」なんかないので、実際の運用では GetAsText で取得できるパスを元に、パスフィールドのバリエーションを作ることになります。

必要パスフィールド

インポート元パス

そんなわけで、これまで「ファイルパス」というフィールド名だったのですが、これを即刻やめて、「インポート元パス」「オリジナルのパス」みたいな名前に替えます。

当然、フォルダインポートをしていないレコードではこのフィールドは空のままです。

これまで阿呆の私は、空である場合にはGetAsTextからパスを生成して同フィールドに記入していました。さらに「file://」を別の(パスとして認識できる)接頭語に勝手に変換したりしていました。そのせいで照合もできなくなり混乱に陥りました。

インポート時に得られるパス情報のメモ書きフィールドは、基本的にそのままの形で温存しておくのが正しい対処です。

接頭語を取っ払った純粋パスフィールド

imagemac:/ だの filemac:/ だの PNGf: だの、無節操な接頭語を取っ払い「 : 」以降だけを抽出します。

これは厳密にはパスではないですが、接頭語を取っ払ったパスフィールドを確保することで、利用に応じて接頭語を付け足したり、他形式に変換したり、あるいは純粋位置情報として、リレーションの照合フィールドにも使えます。

変換されたパスフィールド

環境に応じたパスのフィールドをこしらえます。MacならPOSIXです。

AppleScriptやターミナルにコマンドを送る際、常に必須なPOSIXは、V19の関数を使ってもいいし、substituteで自作関数を作っておいても良いと思います。

変換されたパスフィールド – フォルダ

やや細かな話になりますが、フォルダ以下のファイル群を一括で処理したいことが多いので、ファイル名を除いたフォルダまでのパスフィールドを作っておくことも役に立ちます。

 

Penguin icon 唐突に無関係な個人的日記を書きますが、このブログの画像にも時々登場する猫、とめが2021年8月7日に死んでしまいました。22年間人生を共にしてきまして大往生の筈なのですが、喪失のダメージ大きすぎてしばらく立ち直れそうにありません。なんてこった。 さようならとめ

 

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください