WindowsエディターからSambaパーティションにファイルを保存すると、奇妙な権限が変更されます
SAMBAにマウントされたUnixパーティション上のWindowsエディターから保存されているファイルでパーマが変更されたときに特定の動作が発生する理由を理解しようとしています。
状況：
Unix上に777の権限を持つファイルがあります。
-rwxrwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*ファイルが配置されているディレクトリは、Sambaを介してWindows 7PCからマウントされます。
「Notepad ++」または「Sublime」エディターで編集するためにファイルを開きます。
ファイルを変更して保存すると、UNIX側で権限が次のように変更されます。
-rw-rwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*
通常のWindowsメモ帳でファイルを開いて保存するときに同じ問題が発生しないため、Sambaマウントが原因ではない可能性があると考えました。
したがって、私の最初の考えは、これは、上記のプログラミングエディタが、単にファイルを保存するのではなく、元のファイルの名前を$orig_filename.bakに変更してから、新しいコンテンツを新しいファイルとして保存するように設定されている可能性があるためです。元のファイル名。これは、UltraEditエディターを使用した同じ問題に関する私自身の以前の経験に基づいています。
しかし、それがパーマの変更の理由である場合、私が観察した他の2つの症状を説明するのに途方に暮れています。
まず、最初からバックアップファイルが作成されていません。
次に、Unixシェルの同じディレクトリに（
touchを使用して）新しいファイルを作成する場合、新しいファイルの権限は-rw-rwxrwxではありません。第3に、重要な場合、ファイルのiノード番号は編集後も同じままです。
他に何が問題である可能性があり、それを調査するためにどのような手順を実行できますか？
名前を変更してファイルをバックアップしないようにUEに指示すると、私自身のUltraEditの問題は解消されました。ただし、Notepad ++にはそのようなオプションはありません。
非常によく似た問題を解決しようとしたときに、この質問を見つけました。私の場合の解決策は、smb.confのグローバルセクションにmap archive = noを追加することでした。
根本的な問題は、SambaがDOSからLinuxにアクセス許可をマップする方法です。
Notepad ++がファイルを保存するとき、それはdosファイルの「アーカイブ」属性を設定/リセットしているようです。デフォルトでは、Sambaはこれを使用して、ファイルに対するユーザー権限の実行属性を管理します。
したがって、Sambaパラメーターを設定した場合：
map archive = no
属性はマップされず、ユーザーの実行権限は以前に設定されたとおりに保持されます。
私も同じ状況でした。私にとっては、smb.confファイルのcreatemaskパラメーターの変更を手伝ってくれました。
create mask = 0600 -> create mask = 0700