user1:group1 に属するファイルがあります。グループ１の他のユーザが共同作業を行えるように意図的に権限７７０がある。 user2（group1に属する）でファイルを開くと、ファイルを編集して期待どおりに変更を保存できますが、変更を保存するとファイルの所有権がuser2：user2に変わります。
私がインターネット検索で見つけた最も近いのはこの質問です。ファイル保存時にグループの所有権が変更されないようにするただ「ただ吸いなさい」という意味のようですが、それが5年前のことです。もちろん、まだLinuxデスクトップ環境でコラボレーションができないのは不可能ですが、私が何を間違っているのでしょうか。
答え1
SGID（グループID設定）ビットがディレクトリに設定されている場合、そのディレクトリから生成されたファイルは、作成したユーザーのデフォルトのグループIDではなく、ディレクトリのグループIDを継承します。新しいサブディレクトリも自動的にSGIDビットを設定するため、これを手動で実行する必要はありませんが、既存のサブディレクトリは手動で変更する必要があります。
答え2
何が起こるかは、ファイルの編集に使用するプログラムがファイルを保存するときに新しいファイルを生成することです。変える古いファイル。新しく作成されたファイルは、常にそのファイルを作成したユーザーの所有になります。
この問題を解決するには（プログラムに動作を変更するための明確な方法がない場合）、ファイルを新しい名前で保存してから、次の手順を実行します。
cat newname >oldname
古いファイル（）oldnameの内容をnewname新しいファイル（）の内容に置き換えます。新しいファイルを作成せずに内容を切り取り、再作成してこれを行います。権限や所有権などのメタデータは変更されません。その後、削除してくださいnewname。
別のより明確な解決策は、共同作業のために同様のシステムgitまたは他のバージョン管理システムを使用することです。これにより、各ユーザーは自分の個人情報を見ることができます。コピーこれらのファイルをローカルで処理し、中央リポジトリにチェックインします。ファイルの所有権と権限はもはや問題にならず、誰がいつ何を変更したのかを確認する利点があります（変更をロールバックしたり、開発を別の分岐に分岐することなど）。
ユーザーのローカルコンピュータで変更が適用されている間は、本番システムでファイルの本番チェックアウトを実行できます。テストの結果、期待どおりに機能するように見える場合は、新しい本番コピーがチェックされます（何をしても）。