web-dev-qa-db-ja.com

外部ファイルの変更について警告しないようにCIFS共有をマウントする方法

これは、マウントの現在のfstabエントリです。

//qnap/share /data  cifs noauto,user,username=qnap,uid=1000,gid=1000 0 0

これはほとんど問題なく動作します。

ただし、一部のソフトウェア(例:geditのような基本的なテキストエディター、またはPhpStormのようなより高度なアプリ)を使用して共有上のファイルを開くと、ソフトウェアは時々「外部ファイル変更通知」を報告します。

ファイルのタイムスタンプまたはサイズは変更されず、このコンピューターとNASの両方がNTPによって設定された同じ時間を持ちます。

Geditなどの基本的なLinuxテキスト編集アプリで、これらの「外部ファイルの変更」通知をトリガーする原因を知っている人はいますか?

これを解決するのに役立つマウントフラグを知っている人はいますか?

私は修正に興味があり、これらの通知をトリガーするために下位レベルで何が起こっているのかを知ることに興味があります。

ありがとう、デイブ

2
dtbaker

fstabで、行を

//qnap/share /data  cifs username=qnap,password=<your_pass>,_netdev,uid=1000,gid=1000 0 0

の代わりにパスワードを挿入し、_netdevもメモします。オプション_netdevは、fstabのcifsマウントに常に推奨されます。このオプションは、ネットワークが有効になるまでマウントを遅らせますが、このオプションを除外しても問題は発生しません。

警告は、マウント中にパスワードを提供しなかったためです。

同様のわずかに異なる(資格情報がファイルに保存され、ファイルがfstabで参照される方法)メソッドが here で説明されています。

Edit:ブートの代わりにログイン中にマウントする場合は、noauto(以前と同じように)を使用します。 userおよびsyncオプションもオプションであり、必要に応じて使用します。

5
Fr0zenFyr

Pluma(MATE DesktopのGedit fork)でも同じ問題があります。ローカルのGNU/Linuxマシン(nanosec)とリモートのWindowsマシン(FAT32の場合は約2秒)のファイル変更タイムスタンプの解像度の違いが原因のようです。

Plumaはファイルの書き込みを完了すると、ファイルの変更タイムスタンプを照会して記憶します。 CIFSの場合、この情報はキャッシュされます(元のナノ秒時間を表示します)。しかし、時間が経過し、キャッシュされた属性が期限切れになり、Plumaが外部変更のファイルのタイムスタンプを再度チェックしようとすると、サーバー側のタイムスタンプ(切り上げから2秒の解像度)を取得します。 Plumaはこれを外部修正と解釈し、警告を表示しました。

CIFSがファイル属性をキャッシュしないようにすることでこれを回避しました:fstabactimeo=0オプションを指定します:

//qnap/share /data  cifs noauto,user,username=qnap,uid=1000,gid=1000,actimeo=0 0 0

そのため、Plumaがファイルを保存してタイムスタンプを読み取ると、常に丸みを帯びたサーバー側のタイムスタンプが取得され、迷惑なメッセージの送信が停止されます。

2
xwindows