ローカルバックアップからリストアしたGitリポジトリのアクセス権エラーへの対処

概要

GitHubなどのリモートリポジトリにクローンしておらず、ローカルでのみバックアップしていたGitリポジトリのリストアを試みると、アクセス権の問題でリポジトリを利用できないというケースに遭遇しました。その解決方法の忘備録です。

発生環境

OS : Windows 10 Home 64bit

アプリケーション : Source Tree

リポジトリの種類 : Gitローカル (リモートリポジトリは不使用)

目的 : HDD入れ替えに伴う開発環境の復元。

操作 : 

1. 開発作業用HDD上のローカルのGitリポジトリをディレクトリごとコピーして、バックアップHDD上にローカルのバックアップを作成。
2. 新HDDにWindows 10、Source Treeをインストール。
3. バックアップHDDをつないで、バックアップHDD→新HDDにディレクトリごとコピーして、ローカルのGitリポジトリのファイルをリストア。
4. Source TreeでClone。保存先パスにはリストアした新HDD上のローカルGitリポジトリを指定。この時点ではSource TreeはGitリポジトリを認識している。
5. Source Treeで以下のエラーを示すダイアログが表示され、リポジトリを取り込めない。
   
   
   
   
   
   

上記ダイアログの内容は以下のとおり。

'git log'がコード 128 で終了しました:fatal:detected dubious ownership in repository at 'リポジトリのパス'
'リポジトリのパス' is owned by: 'Gitリポジトリに記録されたオーナー識別子'
but the current user is: '指定したディレクトリのオーナー識別子'
To add an exception for this directory, call:

        git config --global --add safe.directory リポジトリのパス
(リポジトリのパス)

調査

まずはメッセージのとおりgit config --global --add safe.directory リポジトリのパス を試してみたのですが、効果なし。

ちょっとすぐにはわからなかったので、ググってみて見つけたのが以下の記事です。

git submodule update failed with 'fatal: detected dubious ownership in repository at'

この記事ではOSなどの書かれていないようですが、症状はこの記事と全く同じに見えます。さらに回答を読み進めると、2022/8/7のhalt9kさんの回答はWindows10での対処法について書かれています。

この回答によるとGitの問題ではなく、Windowsのディレクトリのアクセス権の問題とのこと。

解決した手順

上記調査結果を参考に、結果として自分は以下の手順で解決することができました。

1. Gitリポジトリのディレクトリの親ディレクトリを右クリック。
2. コンテキストメニューの「プロパティ」を選択。
3. プロパティウィンドウの「セキュリティ」タブを選択。
4. 「詳細設定」ボタンを押下。
5. セキュリティの詳細設定ダイアログが表示されるので、「所有者」を確認しておく。
6. 同ダイアログの下部の「継承の無効化」を押下。
7. 同ダイアログ上部の「変更」を押下。
8. ユーザまたはグループの選択ダイアログの下部の「選択するオブジェクトを～」に、自分のWindowsのアカウント名を入力。
9. 「OK」を押下。
10. セキュリティの詳細設定ダイアログに戻るので、「所有者」が入力したアカウントに変わっていることを確認。
11. Source TreeでGitリポジトリをAddする。

現象発生したリポジトリはドライブ直下ではなく、サブディレクトリ内に置いていたことも影響しているかもしれません。

自分はWindowsではSource Treeを使用していますが、gitで生じる問題なので、たぶんCUIのgitでも同様に解決できると思います。

(2023/8/11追記)

ドライブ直下に置いたGitリポジトリでも同様の現象の発生を確認しました。その場合に最も簡単に解決できた方法は以下のとおりです。ドライブ直下だと面倒なので、サブディレクトリに移したほうが楽でした。

1. Gitリポジトリを格納するためのディレクトリを適当に作る。
2. 作成したディレクトリを右クリックし、上記手順2～6を実施。
3. 「OK」を押下してダイアログ2つを閉じる。
4. Gitリポジトリのディレクトリを作成したディレクトリに、移動ではなくコピーする。
5. Source TreeでコピーしたGitリポジトリをAddする。

サーバレス アーキテクチャ

サーバレス アーキテクチャ って何

ちょっとネットで調べてみればわかるのですが、サーバレス アーキテクチャについて書かれた記事はそこそこ数はあります。しかしどれを読んでも結局サーバレスがどういうものなのか理解できない記事ばかりが目立ちます。よく見るのは以下のような例です。

• こんなサービスですといくつか具体的に紹介されているものの、肝心のサーバレス アーキテクチャそのものについての記述がない。
• あれではない、これでもないと該当しないサービスの例が挙げてあるものの、では何がサーバレスなのかについては記述がない。
• 「サーバレス アーキテクチャとはサーバレスな構成です」としか書いてない。←いや説明を説明してw

このような状況なので、調べてもなかなか良い記事にたどり着きません。記事を書いてる人たちも理解していないのではないかと疑いたくなります。

いきなり結論

サーバレス アーキテクチャとは、常時起動しているサーバが存在しない構成

のことです。文字どおりに「サーバがない」と解釈してしまうと「ではどうやって処理するのか」と疑問が湧くだけですが、常時かどうかがポイントです。

以下、従来と比べるとより分かりやすいと思います。

非サーバレス

サーバレスではない従来の構成では、サーバは起動しておいてリクエストが来るのを待っています。リクエストが来なければ、基本的には何もしないでずっと待ち続けています。

GCPでWebサーバを構成する例だと、GCE/GKEに従来のオンプレミスでの構成と同様にWebフレームワーク等をインストールして構成します。

クラウドでは従量課金が基本ですが、アプリが何もしないで待っている間でもプラットフォームから見れば稼働中なので課金されます。またアプリを動かすインフラがスケーリングに対応していない場合、想定される最大の負荷にあわせて構成することになります。その分ランニングコストが高くなります。

サーバレス アーキテクチャ

アプリが必要になった時点で、プラットフォームがアプリを自動的に立ち上げてくれます。アプリが立ち上がったら非サーバレスと同様に、アプリによってリクエストが処理されます。アプリが稼働を停止していると判断されたら、フラットフォームが自動的にアプリを停止してくれます。

クラウドではこのような動作を可能にするプラットフォームが用意されています。当然アプリもそれにふさわしい作り・設定が必要です。アプリが停止した後は、それまでアプリが動作していたインフラ(CPU、メモリ、ネットワーク、etc.)は、別のアプリのために使用されます。そのためインフラ全体では稼働効率をよくすることができます。

また、アプリ起動がインスタンスの増加と同じになるので、水平スケーリングにも対応が容易です。

GCPでWebサーバを構成するなら、GAEを利用します(ただし最小インスタンス数=0設定)。小規模ならCloud Run/Cloud Functionsも利用できます。GKEでも最小Pod数を0にしてネットワークからリクエストで起動するように設定することも可能(なはず)です。負荷の増減に対しても、その瞬間の負荷をさばくのに必要な数だけアプリを立ち上げればいいだけです。

従量課金だとアプリが稼働している間だけ、立ち上がっている数だけ課金されるので、ランニングコストを抑えることができます。

BigQueryの価格変更とEditions

Googleのブログ記事「データクラウドに柔軟性と予測可能性をもたらす、新たな BigQuery Editions を発表」に載っているように、2023/07/05からBigQueryの料金体系が変わります。すでにネット上では多くの記事が書かれているので、ご存じの方も多いと思います。ここでは主な変更点について説明します。概要の理解を重視し、細かい部分については説明を省いています。またリリースもまだなので、変更される可能性もあります。

ストレージ料金の計算方法の変更

従来からBigQueryに保存されるデータは圧縮されていましたが、ストレージ料金が以下のように変わります。圧縮は平均1/12になるようですので、かなり料金が下がるはずです。

• 従来 : 圧縮前の論理バイト数に応じて課金される。
• 変更後 : 圧縮後の物理バイト数に応じて課金される。

ただし注意が必要なのは、計算方法の変更が自動的に行われるかどうかは未定のようです。圧縮後で計算されるようにするには、7/5以降に何か操作が必要になる可能性があります。  

(2023/09/14追記)

ストレージ料金を論理バイト数から物理バイト数に変更するには、データセット単位で設定の変更が必要です。そのためのUIもすでにGCPコンソールに追加されています。手順は以下のとおり。

1. サイドバーから「BigQuery」→「SQLワークスペース」でエクスプローラを表示。
2. 左ペインでデータセットを選択。
3. データセット情報の右端の「詳細を編集」。
4. 「詳細オプション」をクリックして展開し、下にスクロール。
   
5. 「物理ストレージの課金モデルを有効にする」をチェックして「SAVE」。
   
   

ただし物理バイト数での課金では約2倍の料金になるようです。BigQueryの概要ページには米国での価格が載っています。「ストレージの料金」にはまだ物理バイト数での価格は見当たりませんが、修正が間に合っていないのでしょう。日本での価格は「「IDOLY PRIDE」のBigQuery料金を70%カットしました」に記載がありました。具体的な数値が載っているのでGoogleに直接確認した可能性があります。

オンデマンド検索の料金

従来の定額料金制ではなくオンデマンドでの検索も、7/5以降も引き続き可能です。クエリに使用したデータ量に応じで課金される仕組みも同じです。しかし料金は25%の上昇となります。これが一番 & たぶん唯一の痛い変更ですね。

従来の定額制とEditionsの違い

従来あった月間定額/年間定額とFlex Slotsが廃止され、新たにEditionsが開始されます。Editionsにはサービス内容と料金の違いで3つの選択肢がありますが、それらの違いの詳細は上記Googleのブログ記事や他のネット上の記事をご覧ください。Googleの公式ドキュメントにもすでに「BigQuery エディションの概要」が用意されています。

Editionsはオンデマンドと異なり、クエリに使用する仮想CPUである「スロット」単位での課金になります。スロットを使用した数と時間で課金されます。

つまりEditionsは新しい定額料金制ではありません。設定次第で、定額制の様にも従量制の様にも出来ますし、それらを組み合わせることもできます。

「スロットの自動スケーリングの概要」に説明されていますが、Editionsではプロジェクトごとに2段階の設定でスロットの利用の仕方を定義します。

• ベースライン スロット
  

  Standardでは使用できないようです。
  常時確保するスロットです。従来の月間定額/年間定額で予約するスロットと同じと考えていいと思います。次の自動スケーリングを使用せずベースラインのみ使用するように設定すると、従来の月間定額/年間定額と同等になります。
  従来の月間定額を使用していたプロジェクトは、7/5に自動的に同量のベースラインに変換されるようです。年間定額の場合はその期限が切れたときにベースラインに変換されるようです。

• 自動スケーリング スロット
  

  基本的にはベースラインスロットを使い切った場合に、追加で使用されるスロットです。自動スケーリングなので不要になれば解放されます。前のベースラインを使用せず自動スケーリングのみ使用するように設定すると、完全にオンデマンドに設定することも可能なようです。

現時点ではまだ自動スケーリングの時間間隔や課金の時間軸方向の単位について明確な記載がないのですが、短い時間でスケーリングされ課金の時間単位も短いなら、オンデマンドに近い感覚で使用することができると思います。従来の月間定額/年間定額を利用してきたユーザにとっては、高価な利用料を下げられるかもしれません。

Flex Slotsの置き換え

従来のFlex Slotsは廃止されるので、今まで利用していたならその代用が必要になります。これは「既存のFlexコミットメント」に説明されています。
Flex Slotsを利用するケースで代表的なのは、特定の期間だけBigQueryの負荷を急増させる様なケースです。その期間の直前にFlex Slotsを購入し、期間が終われば削除することで、従来は短期的かつ計画的な負荷の急増に対応することがてきました。

Editionsでは自動スケーリングを設定すれば、このような負荷の急増に対応できます。

BI Engineについて

今回の仕様変更では、BI Engineについてはほとんど言及されていません。「エディションの機能」の表ではStandardプランでは利用できない様です。またこの表の「エディション以外のサービス」はオンデマンドのことを指していると思われるのですが、記述されている内容は従来の内容の様に見えます。そのため単体で利用できるのかどうかも曖昧です。従来は年間定額で一定以上のスロットを予約すればオマケについてくるケースもありましたが、それもどうなるのか不明です。