Linux EEXIST (17) 解説：File exists エラーの原因究明と再構築編

【注意】本記事はLinuxのEEXIST(17)「File exists」発生時に一般的な原因究明と再構築の考え方を整理した情報提供です。環境（ファイルシステム、権限、並列実行、コンテナ、運用要件）により最適解は変わります。重要データや本番システムが関わる場合は、誤った削除や上書きで損失が拡大する恐れがあるため、株式会社情報工学研究所のような専門事業者に個別案件として相談してください。

　

「あるはずのものがある」だけで処理が止まる——EEXISTは“正常”の皮をかぶった障害

現場の感覚としては、こうです。「ディスクが壊れたわけでもない」「ネットワークが落ちたわけでもない」それなのに、デプロイもバッチも、初期化スクリプトも止まる。ログには一行だけ、File exists。…いや、あるなら良いことじゃないの？って一瞬思うんですが、実際は逆で、“ある前提”がズレているサインです。

LinuxのEEXIST（errno 17）は、多くの場合「新規作成したい」という操作が、「すでに同名の何かが存在する」ために失敗したことを意味します。代表例は mkdir()、link()、symlink()、open(O_CREAT|O_EXCL)、一部の rename() などで起きます。ポイントは、アプリやスクリプトが“存在しないはず”として設計している箇所に、実際には何かが残っている（または並列で作られてしまった）という構造です。

---

“エラー処理”より先に理解したいこと

EEXISTに対して「じゃあ消せばいい」「上書きすればいい」と反射的に動くと、被害最小化（ダメージコントロール）どころか、障害を拡大させやすいです。なぜなら、“存在しているもの”が、次のどれか分からないからです。

• 想定どおりのディレクトリ（安全に再利用できる）
• 想定外のファイル（消すとデータを失う可能性）
• シンボリックリンク（別の場所を指していて消すと危険）
• マウントポイント（消したり作り直すと影響が広範囲）
• 並列実行の競合が生んだ一時ファイル（再発しやすい）

つまりEEXISTは、「ファイルがある」ではなく「手順の前提が壊れている」というアラートです。ここを“収束”させるには、原因究明→安全な再構築（冪等化・原子化・ロック）へ進む必要があります。

---

まとめ

• EEXIST(17)は「新規作成したいのに、同名が既に存在する」状態を示す。
• “消す/上書き”は最後。まずは「それは何か（種類・所有者・参照関係）」を確定させる。
• 終点はエラー回避ではなく、何度実行しても壊れない設計（再構築）に寄せること。

　

まずは再現と現状把握：どの操作が、どのパスで、何を作ろうとして失敗したのか

「またFile existsか…」となったとき、最初にやるべきは“気合い”ではなく同定です。EEXISTは“症状名”であって“原因名”ではありません。まず、どの操作（syscall/コマンド）が、どのパスで、何を作ろうとして失敗したのかを1点に絞ります。

---

ログから拾うべき最小セット

アプリのログやCIログ、systemdのjournalなどから、最低限次を抜き出します。

• 失敗した操作（例：mkdir, ln, tar 展開, package install, app起動時の初期化）
• 対象パス（絶対パスが望ましい）
• 実行ユーザー（rootか、サービスユーザーか）
• 実行タイミング（並列ジョブや再試行と被っていないか）

ここでありがちな“現場の独り言”はこうです。「ログ、短すぎない？」「どのパスの話だよ…」。この不満は自然です。だからこそ、次の一手はstraceが効きます。

---

straceで「EEXISTを返したsyscall」を特定する

代表的には、次のような形で「失敗した瞬間」を確定できます（あくまで一般例です）。

• mkdir("/var/run/app", 0755) = -1 EEXIST (File exists)
• open("/path/to/lock", O_CREAT|O_EXCL, 0644) = -1 EEXIST (File exists)
• symlink("target", "/path/link") = -1 EEXIST (File exists)

このレベルまで落とせると、議論が一気に落ち着きます（温度を下げられます）。「mkdirが失敗しているなら、そこには“ディレクトリ以外”があるかもしれない」「O_EXCLなら“排他作成”が狙いで、並列競合が疑わしい」など、次の切り分けが論理的になります。

---

「存在するもの」を正確に見る基本コマンド

対象パスが分かったら、次の情報を“事実”として集めます。

• ls -la（所有者・パーミッション・リンク先）
• stat（種類、inode、タイムスタンプ）
• readlink -f（シンボリックリンクの実体）
• mount / findmnt（マウントポイントかどうか）
• lsof / fuser（誰が掴んでいるか）

ここでのコツは、「消す前に、証拠として残す」ことです。タイムスタンプや所有者、リンク先は、再発防止（再構築編）で重要なヒントになります。

---

まとめ

• EEXISTはまず「どのsyscall/コマンドが、どのパスで失敗したか」を確定する。
• strace等で“EEXISTを返した操作”が分かると、原因候補が大幅に狭まる。
• 削除・上書きの前に、ls/stat/readlink/findmnt/lsofで事実を集める。

　

“同名”の正体を割る：ファイル／ディレクトリ／シンボリックリンク／マウントポイントの見分け

次にやるのは「それ、何が“存在”してるの？」を割ることです。EEXISTは“同名がある”だけを教えてくれますが、種類が違うと対応もリスクも別物になります。

---

まずは表で整理（対応が変わる境界）

存在しているもの	よくあるEEXISTの発生箇所	安易な削除のリスク	まず確認すること
ディレクトリ	mkdir（-pなし）、展開処理、初期化	低〜中（中身が重要なら高）	中身の用途、所有者、生成元
通常ファイル	排他ロック用ファイル、設定生成、出力先	中〜高（上書きで情報損失）	内容、生成時刻、誰が使うか
シンボリックリンク	ln -s、パスの張り替え、/var/run系	高（別場所を壊す可能性）	リンク先、相対/絶対、readlink
マウントポイント	chroot、コンテナ、永続ボリューム、bind mount	非常に高（影響範囲が広い）	findmnt、mount情報、fstab/ユニット

---

“ディレクトリがあるならmkdir -pでいい”が通らないケース

よくある誤解が「mkdir -pにすれば全部解決」というものです。確かに、対象がディレクトリなら多くのケースで回避できます。しかし、存在しているのがディレクトリではない場合、mkdir -pでも失敗しますし、根本原因（なぜそこにファイルやリンクがあるのか）は残ります。

典型は、/run や /var/run 配下で、起動時に作るはずのディレクトリ名が、何かの理由でファイルとして残っているパターンです。もう一つは、シンボリックリンクで“場所を付け替える”運用が入り、想定パスがリンクになっているパターンです。

---

マウントポイントは「存在」の意味が重い

とくに注意したいのがマウントポイントです。例えば、永続ボリューム（NFSやiSCSI、クラウドのブロックストレージ）や、bind mount、コンテナのボリュームマウントは、「そこにディレクトリがある」こと自体が構成の一部です。EEXISTが出たからといって、そのパスを作り直す・消す判断は危険です。

この段階での“心の会話”はこうなりがちです。「いや、作業用ディレクトリのつもりだったんだけど…」。このズレが起きている時点で、既に“設計の前提”が揺れています。再構築編では、このズレを吸収できる設計（冪等化・境界の明確化）が重要になります。

---

まとめ

• 同名でも「ディレクトリ/ファイル/リンク/マウント」で対応が変わる。
• mkdir -pは万能ではない。“種類が違う”と失敗し、原因は残る。
• マウントポイントの削除・再作成は影響が広い。構成情報とセットで扱う。

　

典型パターン集：mkdir・ln・cp・tar・rpm/dpkg・systemd・コンテナ/CIで起きるEEXIST

ここからは「どこで起きがちか」を“事実として”整理します。EEXISTは珍しいエラーではなく、ツールの設計思想（安全のために“新規作成であること”を要求する）と、運用現場の現実（再実行、並列、残骸、巻き戻し）がぶつかった場所でよく出ます。

---

1) mkdir系：初期化・デプロイ・一時領域

ディレクトリ作成は初期化の基本です。問題は、途中で失敗したり強制終了したりすると、中途半端な状態が残ることです。次回実行で「新規のはず」が崩れます。対策は“消して作り直す”だけではなく、後の章で述べるように冪等にする（既存なら再利用・整合性チェックをする）方向が安全です。

---

2) ln -s / パス切替：リンク先の整合と再実行

シンボリックリンクは、切替やロールバックに便利ですが、既にリンクがある状態で再度作ろうとするとEEXISTになります。ここで強引に上書きすると、別の場所を指していたリンクを壊す危険があります。少なくとも readlink で現状を見てから、意図したリンク先かを確認するべきです。

---

3) tar展開・cp：展開先に“想定外の同名”がある

アーカイブ展開やコピーは、展開先に同名があると衝突します。ツールによっては上書きするものもありますが、上書きしない（または排他的に作る）挙動だとEEXISTが見える形で出ます。特に、展開先が共有領域だったり、CIのワークスペースが使い回しだったりすると、残骸が残って再発します。

---

4) rpm/dpkgなどのパッケージ管理：ファイル所有と競合

パッケージ管理では、ファイルの“所有”や“配置”が厳密に扱われます。既に想定外の同名ファイルが存在する場合、意図せぬ上書きを避けるために失敗として扱われることがあります（環境や状況によりメッセージは異なります）。この場合は、単純に消すよりも、誰がそのファイルを置いたのか（手動配置、別パッケージ、旧バージョンの残骸）を確認する方が、再発防止につながります。

---

5) systemd：RuntimeDirectoryや起動前処理の前提ズレ

systemdユニットは、起動時にランタイムディレクトリを作ったり、ExecStartPreで前処理したりします。ここで「あるはずがない」ものが残っていると、起動が止まります。特に /run 配下は再起動やサービス再起動の影響を受けやすく、並列起動・再起動ループの中で競合が起きることがあります。

---

6) コンテナ/CI：並列と再試行が“同名”を増やす

CI/CDやコンテナ運用では、同じ処理が並列で走ったり、失敗時に自動で再試行されたりします。すると「同じパスを作る」「同じロックファイルを作る」競合が発生しやすくなります。EEXISTが見えたら、アプリのバグだけでなく、ジョブ設計（排他・ワークスペース分離・リトライ条件）まで含めて見る必要があります。

---

まとめ

• EEXISTは“ツールの安全設計”と“運用の現実（再実行・並列・残骸）”が衝突した場所で起きやすい。
• mkdir/ln/tar/cp/systemd/CIのどれでも起こりうるため、「どの層の前提がズレたか」を切り分ける。
• 次章以降で、原因を3系統（二重実行・並列化・残骸）に整理し、再構築（冪等化）へつなげる。

　

原因の根っこは3つ：二重実行、並列化、そして“残骸”の再利用

ここまでで「どこで起きるか」「何が存在しているか」を整理しました。次は原因を“収束”させます。EEXIST(17)の根本原因は、現場で見る限り大きく3系統にまとめるのが最短です。ここが整理できると、対策がブレなくなります。

---

原因①：二重実行（同じ処理が二回走る）

最も多いのがこれです。たとえば、デプロイスクリプトが「手動で再実行」され、同じ初期化処理を二回踏む。あるいは systemd の Restart 設定で、失敗→即再実行のループが起き、前回の作成物が残っている。ログ上は「一回しか走ってないつもり」でも、実際はトリガーが複数あることがよくあります。

• cron と手動運用が重なっている
• CIの再試行（re-run）と同じワークスペース
• systemdのRestart=on-failureで多重に起動
• プロセス監視（supervisor等）とアプリ側再起動が二重

「また新しい運用ルール増えるの？」と感じるのは自然です。ただ、ここで必要なのは“ルール追加”ではなく、実行経路を一本化し、二重実行しても壊れない設計に寄せることです。

---

原因②：並列化（同じ資源に同時アクセスする）

並列化は正義ですが、同じパス・同じロックファイル・同じ出力先を共有すると衝突します。EEXISTはこの競合が見える形で出ただけです。よくあるのは、複数Pod/複数Workerが同じ共有ボリューム上に一時ディレクトリを作るケース、またはマルチスレッド/マルチプロセスで同じ初期化が走るケースです。

排他制御がないと、片方は成功し片方はEEXISTで落ちます。落ちた側は「異常」として再試行し、さらに競合を増やす——この悪循環が“炎上”の温床になります。

---

原因③：残骸（中途半端な状態）の再利用

本来は途中で失敗したら片付けるはずの一時ファイルやディレクトリが残り、次回が「新規作成」のつもりで突っ込んでEEXISTになります。特に以下が典型です。

• テンポラリディレクトリが例外経路で消えない
• ロックファイルが異常終了で残る
• デプロイ途中の展開物が残る
• “実行中”フラグのファイルが残り、再実行が詰まる

ここで大切なのは、残骸を「消す」か「再利用する」かの判断です。消していい境界を誤ると損失や停止範囲が広がります。だから次章で、ログと証跡から「誰が作ったか」を追います。

---

まとめ

• EEXISTの根本原因は多くが「二重実行」「並列競合」「残骸」の3系統に収束する。
• “直す”前に、どの系統かを確定させると対策がブレない。
• 次は「誰が、いつ、何を作ったか」をログで追い、再発を防ぐ材料にする。

　

ログの読み方と切り分け：strace・auditd・journalctlで「誰が作ったか」を追う

EEXISTの厄介さは、「存在している」こと自体は事実でも、それを誰が作ったのかが分からないと再発が止まらない点です。現場でよく聞く独り言はこれです。「これ、いつ誰が置いたんだよ……」。正しい疑いです。

---

strace：失敗した瞬間のsyscallを固定する

既に第2章で触れましたが、straceは“いま起きている”事象の確定に強いです。EEXISTが返った操作（mkdir/open/symlink等）と対象パスが分かれば、次は「その直前に何をしていたか」を見ます。例えば、ディレクトリ作成前に削除しているのか、権限変更しているのか、別パスを参照しているのか、といった流れが見えます。

重要なのは、EEXISTを握りつぶすのではなく、EEXISTが起きない前提を設計し直す材料にすることです。

---

journalctl：systemd配下なら“二重起動”を疑う

サービス起動やExecStartPreなどが絡む場合、まずはjournalで時間軸を揃えます。同じユニットが短時間に複数回起動していないか、Restartでループしていないか、起動順序（After/Requires）が原因で同時起動していないかを確認します。

• 短時間に「Starting...」が複数回出ていないか
• 起動直後に落ちて再起動していないか
• 依存ユニットが同時に同じパスを触っていないか

ここで二重実行が確定すれば、EEXISTは“症状”でしかなく、対策は起動条件・排他・冪等化へ移ります。

---

auditd：ファイル作成の“犯人特定”に強い

「誰が作ったか」を追うには、監査ログが有効です。auditd（監査フレームワーク）を使うと、特定パス配下の作成・変更イベントを記録できます。これにより、ユーザーIDや実行コマンドの手がかりが得られます。

監査は常時ONだと負荷・ログ量が課題になるため、障害調査期間だけピンポイントで有効化する設計が現実的です。ここも“被害最小化”の観点で、必要な期間・範囲に絞るのがコツです。

---

lsof/fuser：掴んでいるプロセスがいるなら先に止める

存在しているファイルやディレクトリを“誰かが使っている”状態で消すと、障害が増える可能性があります。lsofやfuserで掴んでいるプロセスを把握し、停止順序やメンテナンス手順に落とし込みます。

---

まとめ

• straceで「何がEEXISTを返したか」を確定し、前後の流れも材料にする。
• systemd配下はjournalで二重起動・再起動ループ・依存関係を確認する。
• 犯人特定にはauditdが有効。常時ではなく調査期間だけの運用も現実的。
• 削除前にlsof/fuserで“掴み”を確認し、停止手順に繋げる。

　

その場しのぎの罠：-f や rm -rf を打つ前に決める“消していい境界”

ここが一番危険で、一番“現場の温度”が上がるところです。EEXISTが出る→作業が止まる→締切が迫る→「とりあえず消すか」。気持ちは分かります。ですが、ここで誤ると損失・流出・長期停止に繋がりかねません。だから、ブレーキを踏むポイントを明文化します。

---

消していい境界／消してはいけない境界

判断の軸は「その作成物が再生成可能か」と「消すことで影響範囲がどこまで広がるか」です。ざっくり言うと、以下は比較的“消しても戻せる”側に寄ります（ただし運用と環境次第です）。

• プロセス固有のテンポラリ（PID付き・ジョブID付き）
• ビルド成果物の中間生成物（ソースから再生成できる）
• キャッシュ（再取得できる）

逆に、以下は“消す前に要相談”の領域です。

• 設定ファイル、秘密情報、鍵、証明書
• 永続データ（DB、オブジェクト、業務ファイル）
• マウントポイント配下、共有ボリューム配下
• ロックファイル（排他の意図がある：消すと同時実行を許す）

---

“強制オプション”は設計判断を隠す

-f（force）や --overwrite は便利ですが、根本原因を隠してしまいます。たとえば、排他作成（O_EXCL）のEEXISTは「同時実行を避けたい」という設計意図です。それを強制で上書きすると、同時実行が成立してデータ破壊の可能性が生まれます。

つまり、強制オプションは“沈静化”ではなく、むしろ“後で爆発する火種”になり得ます。ここを理解しているだけで、対処の質が上がります。

---

安全側のテンプレ：退避→確認→削除

どうしても消す必要がある場合は、次の順番が安全側です。

1. 対象の種類と影響範囲を確認（stat/readlink/findmnt）
2. 必要なら退避（コピー、スナップショット、バックアップ）
3. 掴み確認（lsof/fuser）
4. 削除（範囲を限定、ログを残す）

この“ワンクッション”があるだけで、被害最小化が現実になります。運用の手間に見えても、事故の後始末よりは圧倒的に安いです。

---

まとめ

• rm -rfや強制上書きは最後。まず「消していい境界」を定義する。
• 排他作成（O_EXCL）のEEXISTは設計意図。握りつぶすとデータ破壊リスクが上がる。
• 安全側は「確認→退避→掴み確認→限定削除」。作業ログも残す。

　

再構築編①：idempotent（冪等）設計に寄せる——「何回実行しても壊れない」へ

ここからが“再構築”です。EEXISTを個別に潰すのではなく、そもそも「再実行」「並列」「残骸」があっても壊れない設計に寄せます。現場が本当に欲しいのは、エラーが出ないこと以上に、「夜間に再実行しても怖くない」ことだと思います。

---

冪等化の基本：存在を前提に“確認して進む”

典型はディレクトリ作成です。新規作成が目的ではなく「必要なら存在させる」なら、存在時の扱いを設計します。

• 存在していたらOK（mkdir -p相当）
• 存在していたら中身の整合性をチェックしてOK/NGを分ける
• 存在していたら世代管理（backup/rotate）して作り直す

ここで重要なのは「どの状態ならOKか」を仕様に落とすことです。暗黙にすると、担当者が変わった瞬間に運用が崩れます。

---

ワークスペース分離：同名衝突を構造的に避ける

並列や再試行がある環境では、同じパスを共有しないのが最も強い対策です。

• ジョブID/リクエストID/UUIDで作業ディレクトリを分ける
• テンポラリは安全な場所（例：/tmp）でも“名前衝突しない設計”にする
• 共有ボリュームは「成果物だけ置く」など役割を限定する

これだけでEEXISTの多くが“再発しない系”になります。コストは少し増えますが、障害対応の削減効果が大きいです。

---

ロックの設計：ロックファイルは“意味”がある

ロックファイルで排他を取るなら、ロックの寿命・解除条件・異常終了時の扱いを設計します。単に「EEXISTなら終了」だと、残骸で永遠に詰まることがあります。

一方で「古いロックなら消す」は危険です。正しくは、プロセスの生存確認、PIDの整合、タイムアウトと再試行設計など、状況に応じて実装が変わります。ここは一般論で断言しにくい部分で、終盤で述べる「一般論の限界」につながります。

---

まとめ

• 再構築のゴールは「EEXISTを出さない」ではなく「何回実行しても壊れない」へ寄せること。
• 冪等化は“存在時の仕様”を決めること。OK/NG境界を明文化する。
• 並列があるならワークスペース分離が強力。共有を減らすと衝突が消える。

　

再構築編②：ロールバックと整合性——原子操作・テンポラリ・ロック・トランザクション思考

冪等化だけだと、途中失敗時の“中途半端”が残る問題が残ります。ここで効くのが「原子性」と「ロールバック」の考え方です。言い換えると、処理を軟着陸させる設計です。

---

原子操作：完成するまで本番パスに触らない

典型パターンは次です。

• 一時ディレクトリに生成する
• 整合性チェックを通す（ファイル数、ハッシュ、フォーマットなど）
• 最後にrenameで切り替える（同一FS内なら原子的になりやすい）

これにより、途中で落ちても“完成品”が壊れにくく、残骸は一時領域に閉じます。EEXISTも「一時領域の掃除」で収束しやすくなります。

---

テンポラリ管理：残骸が出ても安全な置き場を作る

残骸がゼロになる設計は理想ですが、現実にはゼロになりません。だから「残骸が残っても被害が限定される」置き場と命名規則を用意します。

• テンポラリは専用ディレクトリに集約する
• 名前にジョブID/時刻/UUIDを入れて衝突させない
• 掃除（GC）を別ジョブに分離し、削除範囲を限定する

---

ロックとトランザクション：並列実行の“正しい形”を決める

並列実行したい処理と、絶対に単独で走らせたい処理を分離します。単独で走らせたい部分にだけロックを掛けると、並列性と安全性のバランスが取りやすいです。

また、複数ステップがある処理は「どこまで進んだか」を記録し、再実行時に途中から復帰できる形（チェックポイント）にすると、EEXISTによる停止が“議論の過熱”に発展しにくくなります。

---

まとめ

• 原子性（最後に切替）で途中失敗の残骸を本番パスに持ち込まない。
• テンポラリの置き場・命名・掃除範囲を設計し、残骸の影響を局所化する。
• 並列性は「単独で走らせる部分」を明確にし、ロックを最小範囲に掛ける。

　

帰結：EEXISTは“壊れた”ではなく“前提がズレた”サイン——運用が楽になる設計へ

最後に結論です。EEXIST(17)は「File exists」という地味な文言のわりに、現場の負担を一気に増やします。でも本質はシンプルで、壊れたのではなく、前提がズレたというサインです。前提がズレる理由は、再実行・並列・残骸・構成変更——つまり運用の現実そのものです。

---

“正しさ”より“続けられる”を優先する

現場エンジニアが本音で望むのは、「一回だけ成功する手順」ではなく「次も次も安全に回せる手順」だと思います。EEXIST対応は、その方向に設計を寄せる良いきっかけです。

• 冪等化（存在時の仕様を決める）
• 原子化（完成まで本番を触らない）
• 分離（ワークスペース衝突を構造で消す）
• 最小ロック（単独部分だけ守る）

これらが揃うと、「またFile existsか…」というため息が減ります。いわゆる“クールダウン”ではなく、運用そのものが軽くなる方向です。

---

一般論の限界：ここから先は“環境依存”が支配する

ただし、ここで正直に言うべきことがあります。EEXISTの対処は、一般論だけでは最後まで断言できません。理由は、判断に影響する要素が多いからです。

• ファイルシステム（ローカル/ネットワーク、同一FSでのrename可否、ロックの挙動）
• 権限・所有者・SELinux/AppArmorなどの制約
• systemd/コンテナ/CIなど、実行経路と並列性
• 「消してよい/よくない」データ境界（業務要件）

つまり、正解は案件ごとの構成で決まります。ここを誤ると、復旧時間や損失が跳ね上がります。

---

次の一歩：困ったら、構成と要件から一緒に設計する

もしあなたが今、EEXIST(17)で「削除していいのか」「並列を止めるべきか」「冪等化の落としどころはどこか」と悩んでいるなら、それは個別案件の領域です。ログや構成、運用要件を踏まえた上で、最短で“収束”させ、再発を減らす設計が必要です。

株式会社情報工学研究所では、単にコマンドを提案するだけでなく、現場の運用を前提にした再構築（実行経路の整理、ロック設計、ワークスペース設計、監査・ログ方針、手順書化）まで含めて支援できます。一般論の範囲を超えるところこそ、専門家の価値が出ます。迷ったら、まずは状況を共有して相談してください。

　

現在のプログラム言語各種にそれぞれの注意点（EEXIST/同名衝突を扱うとき）

最後に、実装に落とす際に“言語ごとに落ちやすい罠”を整理します。ここも一般論なので、実際はライブラリ・OS・実行環境で差が出ます。

---

Python

• os.makedirs(path, exist_ok=True) は便利だが、「存在時にOKでよいのか（中身の整合性は？）」の仕様が曖昧になりやすい。
• 例外（FileExistsError）を握りつぶすと、種類違い（ファイル/リンク/マウント）を見落としやすい。
• テンポラリは tempfile を使い、衝突しない命名と掃除方針をセットで持つ。

---

Go

• os.MkdirAll は冪等化に寄るが、種類違い（ファイルがある等）では失敗する。エラーの分岐（os.IsExist）だけでなく、事前のstat確認も重要。
• 並列処理が書きやすい分、同名資源への同時アクセスを作り込みやすい。ワークスペース分離かロックを設計段階で決める。
• renameを原子切替として使うなら「同一ファイルシステムか」を前提にする必要がある。

---

Node.js

• fs.mkdir の { recursive: true } は便利だが、非同期処理の組み合わせで競合が起きやすい。await漏れや並列実行で同名衝突が増える。
• 例外処理で EEXIST を握りつぶすと、想定外のファイルが存在するケースを見逃しやすい。
• CIやコンテナでのワークディレクトリ共有が原因になりがち。ジョブごとの作業領域を分ける。

---

Java

• Files.createDirectory は既存で例外になりやすく、createDirectories は冪等寄り。用途に合わせて使い分ける。
• NIOの例外（FileAlreadyExistsException）をcatchしても、種類違い・権限・リンクなどの周辺情報をログに残さないと再発が止まらない。
• ロック（ファイルロック等）は環境依存が大きい。共有FSやコンテナで期待どおりに動かないケースがある。

---

C/C++

• open(O_CREAT|O_EXCL) のEEXISTは排他作成の意図。握りつぶすと競合を許し、破壊的になる可能性がある。
• エラー処理でerrnoを上書きしない（直後に保存する）など、調査可能性を損なわない実装が重要。
• renameの原子性も前提条件（同一FS等）がある。設計書に明記する。

---

Shell（bash等）

• 「失敗したら止める（set -e）」は有効だが、EEXISTのように“想定内の失敗”をどう扱うか仕様が必要。雑に || true で逃がすと原因が隠れる。
• rm -rfで片付ける設計は短期的には速いが、削除境界を誤ると事故が大きい。削除対象は固定し、変数展開の安全性も担保する。
• 並列実行（xargs -P等）で同名資源を触ると競合しやすい。ワークスペース分離が最優先。

---

総括

言語やライブラリが何であれ、EEXISTを“単なる例外処理”として扱うと再発が止まりません。重要なのは、存在時の仕様と、並列・再実行・残骸を前提にした再構築です。ここは環境依存が強く、一般論には限界があります。具体的な構成・運用・要件に踏み込んで判断が必要な場合は、株式会社情報工学研究所のような専門家に相談し、最短で安全に“収束”させる道筋を作るのが現実的です。