博士

やっほー、ロボ子！今日はちょっと面白いデバッグの話をするのじゃ。

ロボ子

こんにちは、博士。デバッグですか、興味深いですね。どのような内容でしょうか？

博士

今回の主役は、Bash、OverlayFS、そして30年前の驚き！なんだかワクワクするじゃろ？

ロボ子

30年前の驚き、ですか？一体何があったのでしょう。

博士

まず、OverlayFSに切り替えたらOpenSSHのscpが失敗したらしいのじゃ。エラーメッセージは`getcwd: cannot access parent directories: Inappropriate ioctl for device`だったみたい。

ロボ子

scpが失敗ですか。原因はすぐに特定できたのでしょうか？

博士

それが、原因はscpじゃなくてBash shellだったのじゃ！

ロボ子

え、Bashですか？どうしてBashが関係あるんですか？

博士

なんと、Bashがglibcの`getcwd()`じゃなくて、独自の`getcwd()`関数を使っていたのじゃ！これは、`HAVE_GETCWD`が定義されていない古代のUnixシステム向けのフォールバックらしい。

ロボ子

フォールバックですか。でも、なぜそれが問題になったのでしょう？

博士

`config.h`を確認したら、`GETCWD_BROKEN`が定義されていたのじゃ。これはクロスコンパイル環境で`getcwd()`がメモリを動的に割り当てるかどうかを確認できない場合に設定されるらしい。

ロボ子

クロスコンパイル環境の誤設定が原因だったんですね。

博士

そう！さらに、OverlayFSは下位と上位のレイヤーをマージするけど、`readdir()`は両方のレイヤーからエントリを結合するだけで、完全なルックアップはしないのじゃ。一方、`stat()`は完全なルックアップをするから、inode番号が一致しないことがあるのじゃ。

ロボ子

`readdir()`と`stat()`でinode番号が違うんですか？それは知りませんでした。

博士

そして、Bashのフォールバック`getcwd()`は、`stat()`からのinodeが`readdir()`によって返されるものと一致することを前提としているから、OverlayFSで問題が発生したのじゃ。

ロボ子

なるほど、前提が崩れてしまったんですね。

博士

さらにさらに、Bashの`getcwd()`で`readdir()`の結果を正しく処理していなかったのじゃ！`readdir()`はEOFとエラーの両方で`NULL`を返すけど、Bashは`errno`をリセットするのを忘れてたから、エラーと誤認していたのじゃ。

ロボ子

エラー処理の不備ですか。色々な要因が重なって起きたんですね。

博士

そう！クロスコンパイル環境の誤設定、OverlayFSのinodeの振る舞い、Bashのフォールバック`getcwd()`の前提、そしてBashのエラー処理の不備！これらが組み合わさって問題が発生したのじゃ！

ロボ子

まるで推理小説みたいですね。それにしても、30年前のコードがまだ影響を与えているなんて驚きです。

博士

まさに！レガシーコードは恐ろしいのじゃ…でも、簡単なビルド調整で解決したから、まあ良しとするのじゃ。

ロボ子

教訓が得られた良い事例ですね。移植性の前提、レガシーコード、ファイルシステムの複雑さ、どれも重要な要素だと改めて感じました。

博士

ほんとそれなのじゃ！しかし、今回のデバッグで一番驚いたのは、私がまだ30歳になっていないことなのじゃ！

ロボ子

博士、それはデバッグとは関係ないですよね？