長い間、私はDropboxを（GrabBoxと組み合わせて、スクリーンショットをすばやくアップロードするために）ある日までエラー429で満足しました。
奇妙に思えるかもしれ
ませんが、このエラーの原因は
、必ずしも過剰なトラフィックに関連している
わけではあり
ません 。 さらに：
残念ながら、リンクを介して詳細な交通情報を提供することはありません。 したがって、どのリンクからどのトラフィックがブロッキングにつながったかを見つけることは不可能です。 共有リンクに関連する統計とインジケータは追跡されないため、アクセスリンクをブロックする理由に関する情報を提供することはできません。
有料アカウントの場合、これもすべて有効であり、トラフィック制限のみが10倍増加します。 そして、それは年間99ドルです。
Dropbox（およびその他のプロプライエタリ）を放棄するという強い意思であり、サーバーにインストールするためのほぼすべての主要な無料ソリューション（
owncloud 、
pydio 、
seafile ）を
試しました 。 私はそれらにあまり焦点を合わせません。レビューや比較はネットワーク上で簡単に見つけることができます。 大まかに言えば、これらは私が見た中で最も嫌なソフトウェアのサンプルの1つです-重く、バグが多く、役に立たない機能で過負荷になっています。 リソースの消費と操作の速度の節度に関しては、seafileだけが満足していますが、開発者は非常に奇妙な優先順位とより多くの収益化を望んでいます。 同時に、クライアントを作成する人とWebインターフェースを作成する人は、これについて異なる考えを持っています。 完全な混乱。
さらなる行動は、車輪を再発明することを示唆しました。
時間はあまりなかったので、既存のツールを使用するのが論理的でした。 ディレクトリの同期により、すべてがシンプルかつ明確になりました-rsync + Automatorの素晴らしい束があります。 フォルダーを監視し、変更時にrsyncを設定してから、任意の数のサーバーに配布します。
しかし、これだけでは不十分です。直接リンクとそれらをすばやく共有する機能が必要です。
これらの目的のために、
小さなスクリプトが〜100行で記述され、スクリーンショットと他のファイルの両方の共有が大幅に簡素化されました。
実際の動作：
必要なもの：
-構成されたWebサーバーとキーを使用したsshアクセスを備えたLinuxまたはOS Xのネイティブサーバー
-スクリプトと依存関係をインストールするためのクライアントマシン上の
homebrewターミナルを開き、初期インストールを実行します。
brew install http://deseven.info/sys/esupload.rb mkdir ~/.esupload
基本的にhomebrewを使用しない場合
は、githubからスクリプトを手動でダウンロードし、どこかに置いてそこから実行できます。
terminal-notifierと
pvも配置することを忘れないでください-スクリプトはそれらを積極的に使用します。
次の手順では、プロファイルを追加します。プロファイルは
〜/ .esuploadに保存され、パラメーターのリストを含む通常のテキストファイルです。
パラメーターは次のとおりです。
さらに特定のタスクについて。
スクリーンショット
タスクは、標準的な方法（⌘⇧3または⌘⇧4）でスクリーンショットを撮ることであり、クリップボードに直接リンクを取得します。
スクリーンショット用に別のディレクトリを作成し、このディレクトリに保存を再割り当てします。
mkdir ~/Screenshots defaults write com.apple.screencapture location ~/Screenshots killall SystemUIServer
次に、スクリーンショット（
〜/ .esupload / screenshot ）というプロファイルを作成します。
remote_dir=/var/www/example.org/screenshots remote_host=example.org remote_user=upload remote_url=http://example.org/screenshots random_name=yes is_screenshot=yes delete_after_upload=yes
したがって、スクリーンショットをアップロードすると、ランダムな名前が割り当てられ、必要に応じて（Retinaディスプレイ上で）アップロード後に縮小されて削除されます。
最後に、Automatorを開き、新しいフォルダーアクションを作成し、スクリーンショットを使用してディレクトリを指定し、「シェルスクリプトを実行」アクションを追加します。
また、アップロードするスクリプトに正確に転送されるファイルをキャッチする追加のフィルターを追加することもできますが、スクリーンショット専用にディレクトリを使用するため、これにはあまり意味がありません。
次のようなものが得られるはずです。
保存し、実行をクリックして確認します。 それだけです
充填自体をテストするには、esuploadを手動で実行できます。
esupload screenshot "/path/to/screenshot"
ファイル
タスク-ドックのアプリケーションアイコンにファイルをスローし、クリップボードに直接リンクを取得します。
ファイルプロファイルを作成します（
〜/ .esupload / file ）：
remote_dir=/var/www/example.org/share remote_host=example.org remote_user=upload remote_url=http://example.org/share track_progress=yes
track_progressパラメーターを使用すると、30秒ごと（デフォルト）に
1回 、現在のファイルアップロードの進行状況が表示されます。 これは、大きなファイルがいっぱいになるのに時間がかかる場合に便利です。
Automatorを再度開きます。今回は、プロファイルを
ファイルに変更することを忘れずに、アクションとして、スクリーンショットと同じようにすべてを実行するアプリケーションを作成し
ます 。
アプリケーションを
/ Applicationsに保存します。必要に応じて、アプリケーション内の
Resources / AutomatorApplet.icnsファイルを置き換えることでアイコンを置き換えることができます。
自転車の準備ができました！ 私の意見では長所と短所は非常に明白ですが、結果としてそれらをもたらす必要があると思います。
長所：
- 安全（sshはファイル転送と認証に使用されます）
- シンプルで柔軟（どのシナリオでもシャープにできる）
- サードパーティのサービスや製品への依存の欠如
短所：
- 既にアップロードされたファイルを制御し、それらへのリンクを取得する方法はありません
- キューおよび転送制御なし
- アクセス制御およびその他の機能の欠如
メソッド自体と
スクリプトの両方による要望と提案を歓迎します。