dosya CLIでフォルダーをアップロードする

コマンドラインからワークスペースとフォルダーのフラグ、再帰的なパス、進捗、部分的な失敗の報告、再開可能な転送を使ってフォルダーをアップロードします。

最終確認日

スクリーンショットは英語版の画面です。

dosya upload ./sample-source --recursive --workspace ws_exampleを使ってコマンドラインからフォルダーをアップロードします。ワークスペースのプレースホルダーを実際のIDに置き換えてください。既定ではdosyaはsample-sourceという名前の保存先フォルダーを作成または再利用し、その下のファイルパスを維持します。--contentsを指定すると、内容が選択した保存先に直接配置されます。

「dosya CLIでフォルダーをアップロードする」の手順。再帰アップロードコマンドを実行し、転送の概要を保存します。保存先には想定どおりのフォルダー構造が表示されます。
「dosya CLIでフォルダーをアップロードする」の手順。再帰アップロードコマンドを実行し、転送の概要を保存します。保存先には想定どおりのフォルダー構造が表示されます。スクリーンショットを原寸で開く。

この手順図はイメージです。以下のフラグと上限は、現在のコマンドパーサーと転送の実装に照らして確認しています。

認証して保存先を選択する

CLIをインストールし、dosya upload --helpを確認してください。プロフィール → APIキーでAPI:APIキーを作成を選択し、参照とアップロードのためにフルアクセスを選び、プロトコルの制限でREST APIを許可してください。必要に応じて対象のワークスペースに固定します。キーを生成の後にキー全体を保存してください。

dosya auth login
dosya workspace list
dosya workspace use ws_example

入力内容が表示されない**Enter API key:**プロンプトに認証情報を入力してください。ws_exampleをワークスペース一覧で返されたIDに置き換えます。最後のコマンドで既定値が保存されます。これを省略して、アップロードのたびに--workspaceを指定することもできます。環境変数で指定されたDOSYA_API_KEYは保存済みキーより優先されます。CLIの保存済み設定は1つで、名前付きアカウントプロファイルはありません。非公開ファイルの転送前に認証済みアカウントとワークスペースを確認してください。

メンバーとして、アップロードと必要なフォルダーの作成が許可されている必要があります。アップロード専用キーでは参照と検証の手順を実行できず、読み取り専用キーではアップロードできません。フルアクセスキーにもワークスペースのルール、キーの制限、ストレージ容量、フォルダーの制限が適用されます。既存フォルダーを選択するには、dosya ls --workspace ws_exampleからIDを取得し、--folder fld_exampleを渡してください。フォルダーは選択したワークスペースに属し、許可されたアクセス範囲内にある必要があります。

アップロード前にローカルの構造を確認する

  • ネストされたフォルダーは再帰的に走査されます。.envやドットファイルなど、隠しファイルである通常ファイルも含まれます。このコマンドには除外ファイルや除外フラグがありません。秘密情報やアップロードしないファイルが含まれる場合は、内容を選別した元フォルダーを用意してください。
  • ネストされたシンボリックリンク、ソケット、デバイス項目はスキップされ、通常出力に**Skipping … non-regular file(s)**と表示されます。指定した最上位パスは通常のファイルシステムのstatで解決されるため、リンク先を避けたい場合は元のパスにシンボリックリンクを使用しないでください。
  • 受け入れられたファイルに必要なフォルダーのみ作成されます。空のサブフォルダーはコピーされず、通常ファイルがない場合は処理が失敗し、**Directory is empty.**と表示されます。
  • 同じ保存先フォルダーにある一致する有効なファイル名は、別のファイルではなく新しいバージョンとして扱われます。これはアップロードであり、差分同期の比較ではありません。変更のないファイルでも再実行によりバージョンが作成されることがあります。リモートにのみあるファイルは削除されません。

転送と検証が終わるまで元のファイルを変更しないでください。保存先に作業中のコピーがある場合は、まず新しいテスト用フォルダーを選んでください。

手順:フォルダーをアップロードする

dosya upload ./sample-source --recursive --workspace ws_example --parallel 3

既存のリモートフォルダーの下に配置する場合:

dosya upload ./sample-source --recursive --workspace ws_example --folder fld_example

余分なsample-sourceの階層を省く場合:

dosya upload ./sample-source --recursive --contents --workspace ws_example --folder fld_example

スペースを含むローカルパスは引用符で囲んでください。--recursiveの短縮形は-r、--workspaceの短縮形は-wです。ファイルの並行数の既定値は3、上限は16です。--parallelまたは-cで設定でき、ワークスペースのセッション上限が低い場合はCLIがフォルダーアップロードの並行数を下げます。単一のマルチパートファイルでは、このフラグはパートの並行数を制御します。

5 MiB以下の小さい通常ファイルは、最大200ファイル、ファイルデータ合計48 MiBのリクエストにまとめられます。このバッチは最大4件まで、選択した並行数を超えない範囲で同時に実行されます。バッチを使用できない場合は個別アップロードに切り替わります。50 MiBを超えるファイルは10 MiBのパートを使う再開可能なアップロードになり、最後のパートはそれより小さい場合があります。これらは転送のしきい値であり、任意のサイズのファイルをアップロードできることを保証するものではありません。拡張子ルール、最大ファイルサイズ、メンバーの容量、利用可能なストレージによって拒否される場合があります。

CLIはフォルダー作成前にワークスペースのルールを読み込みます。通常出力には拒否されたパスが最大10件表示され、受け入れられたファイルの処理は続行されます。ルール違反がスキップされた場合、フォルダー全体のアップロードが完了した証拠にはなりません。--jsonを指定すると、拒否されたファイルがある場合はfiles_rejectedを出力し、フォルダー作成前にコード2で終了します。推定容量が上限に収まらない場合、クライアントは警告し、各ファイルの判断をサーバーに委ねます。一部が失敗する場合があります。

結果を読み、リモートの構造を検証する

通常出力には最初にファイル数と合計サイズが表示されます。対話形式の進捗はstderrに出力され、続いて**Done. N uploaded, M failed.**と表示されます。スクリプトでファイルIDと各ファイルの結果が必要な場合はJSONを使用してください。

dosya upload ./sample-source --recursive --workspace ws_example --json > upload-result.json

フォルダーの結果にはuploaded、failed、failures、filesが含まれ、成功した項目にはファイルID、名前、サイズ、バージョンが含まれます。JSONに加えてプロセスの終了ステータスも確認してください。転送またはフォルダー作成が失敗すると、他のファイルが完了していても1で終了します。共通のエラーカテゴリーには、使い方の2、認証の3、ネットワークの4、権限拒否の5、メンテナンスの75もあります。成功は0です。

同じワークスペースのファイルを開き、作成されたルートフォルダーとその配下のフォルダーを確認してください。ファイル名、サイズ、想定件数をローカルの構造と比較し、代表的なファイルをダウンロードして開いてください。スキップされたパスと警告をすべて確認してください。フォルダー作成の警告により、配下のファイルが作成済みの親フォルダーに配置される場合があります。成功件数だけではフォルダー構造が正しいことを確認できません。

中断、再開、安全な再試行

Ctrl+Cを押すと**Interrupted.**と表示され、130で終了します。完了したファイルと作成済みフォルダーはクラウドストレージに残ります。中断はトランザクションのロールバックではなく、それらは削除されません。

マルチパートファイルでは、クライアントはデータ送信前に<local-file>.dosya-uploadを書き込み、完了後に削除します。同じファイルを後でアップロードする場合、バイトサイズと更新日時が一致し、再開用URLが設定済みのAPIホストに属していれば、保存済みパートを再利用できます。再開可能な再試行のためにサイドカーファイルを保持し、編集しないでください。単一ストリームのアップロードは一時的な問題に対して1秒、3秒、8秒待機した後、最大3回再試行します。4xxによる拒否は一時的なエラーとして再送されません。

フォルダーのアップロードが中断された場合は、概要と保存先の一覧から未完了ファイルを特定し、それぞれ既存のフォルダーIDに向けて再試行してください。構造全体を無条件に再実行すると、成功済みファイルも再びアップロードされ、余分なバージョンが作成される場合があります。スキャナーは通常ファイルの.dosya-uploadサイドカーファイルも含めるため、再帰的な再実行は対象を絞った再開処理とは異なります。古いセッションが使えなくなった場合は、意図的に最初からやり直す際にそのファイルのサイドカーファイルだけを削除してください。ローカルのサイドカーファイルを削除しても、クラウドに保存済みのファイルには影響しません。

拒否の内容に応じて対処する

出力次の操作
Use --recursive to upload a directory.元の構造を確認してから--recursiveを追加してください。
Workspace ID required.--workspaceを指定するか、dosya workspace useで既定値を設定してください。
Every file was refused by this workspace's upload rules.拡張子とサイズの制限を確認し、入力を変更せずに再試行しないでください。
--version-of can only be used with a single file.通常の再帰アップロードを使うか、バージョンの対象を明示して置き換えるファイルを1件アップロードしてください。
Warning: failed to create folder件数だけに頼らずファイルの配置先を確認し、フォルダーの権限または保存先を修正してから再試行してください。

--version-ofフラグは単一ファイルで使用でき、フォルダーでは使用できません。既存ファイルを明示的に対象にできます。バージョンの復元はワークスペースの履歴保持期間に制限されるため、検証が完了するまで元のローカルフォルダーを保持してください。

期待される結果

受け入れられたファイルは、選択した保存先の下に想定どおりの相対パスで表示されます。—contentsを使用した場合は保存先に直接表示されます。完全な結果にはアップロード済みファイルのほか、スキップ/拒否されたパスや部分的な失敗も含まれます。フォルダーの完了を判断する前に確認してください。

関連ガイド

この記事は役に立ちましたか?

評価の結果を読み込んでいます…

投票すると、回答を変更できるように、必要な投票用Cookieが最長180日間保存されます。

質問と回答

このガイドの手順について質問できます。質問は確認後に公開されます。

公開の質問には、アカウントの詳細、認証情報、非公開ファイルを含めないでください。これらについては 非公開サポート をご利用ください。

質問を読み込んでいます…

    dosyaアカウントにサインインすると、質問を投稿できます。

    やり直す前に結果を確認

    操作をもう一度確認する必要があるときは、次の共通の確認事項をご利用ください。