FileMakerメディア ファイルパス

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

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

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

何を間違っていたか

パス

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

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

FileMakerのパス

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

純粋なパスはない

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

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

何が同じなんだか💦💦

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

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

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

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

何が同じなんだか💦💦

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

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

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

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

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

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

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

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

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

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

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

FileMakerで取得できるパス

改めまして、FileMaker で取得出来るパスのようなものは以下の通りです。

接頭語 + パス

file: とか image: とか、接頭語が付いたパスです。
“file:/volume/folder/file.jpg” のような書き方になります。これがFileMaker仕様のパスです。

接頭語には、file, image, movie があり、プラットフォーム別にさらに細かく filemac, filewin, filelinux などそれぞれがあります。fmnet という書き方もあるそうです。

どういう場合にどの接頭語を使うのかよくわかりませんが、すべてに対応する「 file: 」を使うのが良いと思っています。

スクリプトなどからパスを指定する場合、接頭語付きの書式を指定します。関数や一部スクリプトでは接頭語がないパスの形でも動く場合もあります。接頭語のあるなしで挙動が異なるわけですが、どのような場合に接頭語が必要・不要なのか、その法則は今のところ判りませんので試して判断するしかないです。法則をご存じの方は是非教えてくださいませ。

パスベース

“/ボリューム” から始まるベーシックなパス表記です。

GetAsText でオブジェクトを指定すると file: /volume/folder/file.jpg のような形で取得できますが、最初の「 file:」 はFileMaker仕様のパスの接頭語ではなく、GetAsText のキー(項目名)です。ここ、大変ややこしいところです。「/volume/folder/file.jpg」この部分が値で、接頭語のないパスです。当ブログの執筆者はこれを勝手に「FMパスベース」と呼んでいます。

GetAsText で取得できる「file:/volume/folder/file.jpg」をFMパスに変換するには、「”file:” & GetAsTextの値」としなければなりません。

パスベースだけではFileMakerのスクリプトでパスを指定する場合、上手く動かないことがあります。その場合は「file:」と、接頭語を加えてFM仕様のパスの形を作ってやる必要があります。

※ 尚、後に GetAsText についての研究成果を公開しました。

GetAsText ( オブジェクト ) の秘密 [FileMaker]

インポート元パス

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

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

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

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

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

必要パスフィールド

ここからはメディア管理を作っていく上でのお話になります。

インポート元パス

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

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

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

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

接頭語を取っ払った純粋パスベース

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

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

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

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

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

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

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

 

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

 

コメントを残す

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

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