マウントされたNTFSボリュームからゴミ箱を管理しようとすると、その上で FreeDesktop.orgのリファレンス を読んでしまいました。
いろいろとテストして、Ubuntu/Gnomeが100%仕様に従っていないことに気付きました。その理由は次のとおりです。
非/パーティションの場合、italwaysは<driveroot>/.Trash-<uid>
を使用し、Itnever事前に作成した場合でも、<driveroot>/.Trash/<uid>
を使用しました。これは機能しますが、面倒です。15人のユーザーがいる場合、ドライブに15個の/.Trash-xxx
フォルダーがありますが、他のアプローチでは1つのフォルダー(15個のサブフォルダー)が残ります。私のドライブの「汚染」は非常に不快です。また、仕様では「($topdir/.Trash
ディレクトリが存在しない場合、$topdir/.Trash-$uid
ディレクトリが使用されます」と記載されています。まあ、それは存在しているので、なぜそれを使用しないのですか?
ルートトラッシュはnot動作しますが、少なくとも箱から出してはいけません。 rootとしてnautilusを開き、ゴミ箱をクリックします。エラーが発生します。ファイルを削除しようとすると、「ゴミ箱に移動できません」と表示されます。わかりました、これは/root/.local/share
を作成することで修正できることを知っています。しかし、仕様では、「「ホームゴミ箱」ディレクトリを新しいユーザーに対して自動的に作成する必要があります。このディレクトリがゴミ箱操作に必要であるが存在しない場合、実装は警告なしで自動的に作成する必要があります。または遅延。」。なぜエラーなのですか?バグ?
ボリュームがすべてのユーザーのRWとしてすでにマウントされている場合、マウントされたボリュームの/etc/fstab
エントリを変更し、uidやguidなどのオプションを追加する必要があるのはなぜですか?
これらは、標準からの逸脱のほんの一例です。したがって、質問は次のとおりです。
」Ubuntuが仕様に100%準拠していない場合、HOWexactlyゴミ箱は機能しますか?Ubuntuの実装に関するテクニカルリファレンスはどこにありますかのゴミ?」
ちなみに、Ubuntuが仕様に従っている場合、特に/.Trash-<uid>
対/.Trash/<uid>
の問題に関して、私が間違っていることを教えてください。
ありがとう!
編集:
詳細情報:
特定のfsがスティッキービット(VFAT、NTFS)をサポートしていない場合、おそらくアクセス許可も持っていません(少なくともVFATは確実にサポートしていません)。では、あるユーザーが/
をパージして他のユーザーの./Trash-xxx
を復元できないのはなぜですか?自分のゴミ箱を読み書きできる場合、他の人のゴミ箱を含むドライブ全体に対して同じことを行うことができますか?または、GnomeにはVFAT/NTFS fs上の./Trash-xxx
フォルダーに対する何らかの「余分な」保護がありますか?
Linuxが/fstab
uidおよびgidオプションを編集することにより、NTFSマウントのファイル許可を「エミュレート」できる場合、スティッキービットも「エミュレート」できますか?私は本当に/.Trash/xxx
形式を使用したいと思います...
ルートの問題:/パーティションでは、ゴミ箱をルートとして使用でき、/root/.local/share/Trash
に移動します。しかし、(ルートとして)Nautilusの「ゴミ箱」をクリックすると、エラーが発生します。そうじゃない?したがって、ファイルは正しくゴミ箱に移動されますが、アクセスできません。 (/root/.local/share/Trash
のファイルを削除して)手動で「パージ」するだけですが、復元は非常に注意が必要です(情報ファイルを開いて手動で移動するなど)。
/以外のパーティション(または、少なくともVFAT/NTFSの場合)では、ルートとしてゴミ箱を使用することさえできません:./Trash-0
フォルダを作成せず、単に「ゴミ箱に入れられません、永久に削除しますか?」どうして?
Fstabについて:NTFSパーティションの永続的なマウントに使用します。私にはいくつかありますが、「事前にマウントされていない」場合は、デスクトップやNautilusを本当に混乱させます。 /data
、/windows/xp
、/windows/Vista
などのマウントに事前にマウントして、ファイルシステムに統合し、/media
とその真のリムーバブルドライブ専用の「マウント/アンマウント」の柔軟性。
それで、Ubuntu/Gnomeが本当に仕様に従っている場合、根本的な問題を修正し、(少なくとも)fstab'ed NTFS固定パーティションのスティッキービットを「エミュレート」する方法はありますか?
私が理解している限り、GNOMEは.Trashを正しく使用しています-gio/glocalfile.cソースを見ると、.Trashディレクトリが存在する場合、それを使用しようとすることがわかります。ただし、ごみ箱ファイルを安全に保存できるようにするには、ディレクトリに正しいアクセス許可が必要であることに注意してください(ここでは安全に、他のユーザーはごみ箱にあるファイルを復元できません)。このGNOMEでは、.Trashディレクトリにスティッキービットを設定する必要があります-FreeDesktop.OrgのTrash仕様のTrash Directories、note(1)を参照してください。
上記のアプローチの主な問題は、あなたが見つけるほとんどのr/wリムーバブルメディアはFATであり、スティッキービットをサポートしていないため、これを安全に処理する唯一の方法はユーザーごとのゴミディレクトリを使用することです。
ルートのゴミ箱について-あなたが説明した問題を再現することはできませんが、私にとってはうまくいくようです。
/ etc/fstabについて-私はそこに何の問題があるのか分かりません:外部ファイルシステムがマウントされている場所を完全に制御したいのでなければ、fstabをいじる必要があります。通常、リムーバブルメディアは、現在アクティブなユーザーの/ mediaで検出されると自動的にマウントされますが、他のユーザーはアクセスできなくなります。別のセットアップが必要な場合は、構成ファイルをいじる必要があります。しかし、それがゴミにどのように関係しているかはわかりません。
少し遅れましたが、誰かが興味を持っている場合:、私は同じ問題を抱えていましたが、アドバイスでDolphinをダウンロードしました。次に、ターミナルでSudo dolphin
を介してDolphinを実行しました。
ここで、ごみ箱を右クリックして空のごみ箱を選択すると、エラーが発生するのではなく、ファイルがクリアされます。
これは実際にはあなたの質問とは関係ありませんが、単に回避策です。