Suppress/bypass “file has changed” errors when editing cifs/Samba files
up vote
3
down vote
favorite
[I originally posted about this on the vi/vim stackexchange, but it's increasingly clear that the core issue is more the filesystem than the editor that's complaining about it]
TL;DR -- Files on a CIFS mount are "changing" in the background in a way that alarms Vim when I try to write to them. I need help either calming Vim or removing the underlying "modification" noise.
Background:
- I have a Linux Guest virtual machine (Arch/Manjaro-i3 64-bit) running on VirtualBox under a Windows 10 Host machine.
- The host machine has a partition formatted as NTFS that is intended to be shared between the two.
- The shared partition is shared via standard Windows 10 sharing, and mounted on the Linux guest as a cifs drive in /etc/fstab.
- I'm editing files from the Guest system using vim 8.1.
Problem:
- Most of the time (apparently at random) I try to :write a file I'm editing in vim, I get
WARNING: The file has been changed since reading it!!!
- I know the contents have not changed on disk between the two writes.
I want to prevent the bogus warning, and also to better understand how to examine its provenance.
Basically, immediately after I write a file to disk, something is making a triggering modification to the file. I suspect the Samba infrastructure, but I'm not sure how to pin this down. I've looked at strace logs, but I'm not super skilled at making sense of that data.
I suspect the issue is some latency between when vim thinks it timestamped the file, and what timestamp gets recorded by Samba when it eventually sees the write-op, such that vim thinks it might be out of date.
But I'm not sure... And if that's true, I'm still not savvy enough to fix it.
Suggestions?
files mount virtualbox cifs
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
asked Jul 2 at 14:54
traeki
162
This question has an open bounty worth +50
reputation from Catskul ending in 3 days.
Looking for an answer drawing from credible and/or official sources.
|
show 1 more comment
up vote
3
down vote
favorite
[I originally posted about this on the vi/vim stackexchange, but it's increasingly clear that the core issue is more the filesystem than the editor that's complaining about it]
TL;DR -- Files on a CIFS mount are "changing" in the background in a way that alarms Vim when I try to write to them. I need help either calming Vim or removing the underlying "modification" noise.
Background:
- I have a Linux Guest virtual machine (Arch/Manjaro-i3 64-bit) running on VirtualBox under a Windows 10 Host machine.
- The host machine has a partition formatted as NTFS that is intended to be shared between the two.
- The shared partition is shared via standard Windows 10 sharing, and mounted on the Linux guest as a cifs drive in /etc/fstab.
- I'm editing files from the Guest system using vim 8.1.
Problem:
- Most of the time (apparently at random) I try to :write a file I'm editing in vim, I get
WARNING: The file has been changed since reading it!!!
- I know the contents have not changed on disk between the two writes.
I want to prevent the bogus warning, and also to better understand how to examine its provenance.
Basically, immediately after I write a file to disk, something is making a triggering modification to the file. I suspect the Samba infrastructure, but I'm not sure how to pin this down. I've looked at strace logs, but I'm not super skilled at making sense of that data.
I suspect the issue is some latency between when vim thinks it timestamped the file, and what timestamp gets recorded by Samba when it eventually sees the write-op, such that vim thinks it might be out of date.
But I'm not sure... And if that's true, I'm still not savvy enough to fix it.
Suggestions?
files mount virtualbox cifs
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
asked Jul 2 at 14:54
traeki
162
This question has an open bounty worth +50
reputation from Catskul ending in 3 days.
Looking for an answer drawing from credible and/or official sources.
How is the Windows share mounted? Smbfs or cifs?
– AlexP
Jul 2 at 16:19
@AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1
– traeki
Jul 2 at 18:01
This answer (on AskUbuntu) suggestsactimeo=0as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The optionactimeo=0suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is.
– AlexP
Jul 2 at 21:09
It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief.
– traeki
Jul 2 at 21:31
As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files...
– AlexP
Jul 2 at 23:15
|
show 1 more comment
up vote
3
down vote
favorite
up vote
3
down vote
favorite
[I originally posted about this on the vi/vim stackexchange, but it's increasingly clear that the core issue is more the filesystem than the editor that's complaining about it]
TL;DR -- Files on a CIFS mount are "changing" in the background in a way that alarms Vim when I try to write to them. I need help either calming Vim or removing the underlying "modification" noise.
Background:
- I have a Linux Guest virtual machine (Arch/Manjaro-i3 64-bit) running on VirtualBox under a Windows 10 Host machine.
- The host machine has a partition formatted as NTFS that is intended to be shared between the two.
- The shared partition is shared via standard Windows 10 sharing, and mounted on the Linux guest as a cifs drive in /etc/fstab.
- I'm editing files from the Guest system using vim 8.1.
Problem:
- Most of the time (apparently at random) I try to :write a file I'm editing in vim, I get
WARNING: The file has been changed since reading it!!!
- I know the contents have not changed on disk between the two writes.
I want to prevent the bogus warning, and also to better understand how to examine its provenance.
Basically, immediately after I write a file to disk, something is making a triggering modification to the file. I suspect the Samba infrastructure, but I'm not sure how to pin this down. I've looked at strace logs, but I'm not super skilled at making sense of that data.
I suspect the issue is some latency between when vim thinks it timestamped the file, and what timestamp gets recorded by Samba when it eventually sees the write-op, such that vim thinks it might be out of date.
But I'm not sure... And if that's true, I'm still not savvy enough to fix it.
Suggestions?
files mount virtualbox cifs
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
asked Jul 2 at 14:54
traeki
162
[I originally posted about this on the vi/vim stackexchange, but it's increasingly clear that the core issue is more the filesystem than the editor that's complaining about it]
TL;DR -- Files on a CIFS mount are "changing" in the background in a way that alarms Vim when I try to write to them. I need help either calming Vim or removing the underlying "modification" noise.
Background:
- I have a Linux Guest virtual machine (Arch/Manjaro-i3 64-bit) running on VirtualBox under a Windows 10 Host machine.
- The host machine has a partition formatted as NTFS that is intended to be shared between the two.
- The shared partition is shared via standard Windows 10 sharing, and mounted on the Linux guest as a cifs drive in /etc/fstab.
- I'm editing files from the Guest system using vim 8.1.
Problem:
- Most of the time (apparently at random) I try to :write a file I'm editing in vim, I get
WARNING: The file has been changed since reading it!!!
- I know the contents have not changed on disk between the two writes.
I want to prevent the bogus warning, and also to better understand how to examine its provenance.
Basically, immediately after I write a file to disk, something is making a triggering modification to the file. I suspect the Samba infrastructure, but I'm not sure how to pin this down. I've looked at strace logs, but I'm not super skilled at making sense of that data.
I suspect the issue is some latency between when vim thinks it timestamped the file, and what timestamp gets recorded by Samba when it eventually sees the write-op, such that vim thinks it might be out of date.
But I'm not sure... And if that's true, I'm still not savvy enough to fix it.
Suggestions?
files mount virtualbox cifs
files mount virtualbox cifs
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
asked Jul 2 at 14:54
traeki
162
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
asked Jul 2 at 14:54
traeki
162
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
edited Jul 2 at 16:01
jasonwryan
48.7k14134184
48.7k14134184
asked Jul 2 at 14:54
traeki
162
asked Jul 2 at 14:54
traeki
162
asked Jul 2 at 14:54
traeki
162
162
This question has an open bounty worth +50
reputation from Catskul ending in 3 days.
Looking for an answer drawing from credible and/or official sources.
This question has an open bounty worth +50
reputation from Catskul ending in 3 days.
Looking for an answer drawing from credible and/or official sources.
How is the Windows share mounted? Smbfs or cifs?
– AlexP
Jul 2 at 16:19
@AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1
– traeki
Jul 2 at 18:01
This answer (on AskUbuntu) suggestsactimeo=0as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The optionactimeo=0suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is.
– AlexP
Jul 2 at 21:09
It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief.
– traeki
Jul 2 at 21:31
As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files...
– AlexP
Jul 2 at 23:15
|
show 1 more comment
How is the Windows share mounted? Smbfs or cifs?
– AlexP
Jul 2 at 16:19
@AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1
– traeki
Jul 2 at 18:01
This answer (on AskUbuntu) suggestsactimeo=0as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The optionactimeo=0suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is.
– AlexP
Jul 2 at 21:09
It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief.
– traeki
Jul 2 at 21:31
As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files...
– AlexP
Jul 2 at 23:15
How is the Windows share mounted? Smbfs or cifs?
– AlexP
Jul 2 at 16:19
How is the Windows share mounted? Smbfs or cifs?
– AlexP
Jul 2 at 16:19
@AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1
– traeki
Jul 2 at 18:01
@AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1
– traeki
Jul 2 at 18:01
This answer (on AskUbuntu) suggests
actimeo=0 as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The option actimeo=0 suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is.– AlexP
Jul 2 at 21:09
This answer (on AskUbuntu) suggests
actimeo=0 as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The option actimeo=0 suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is.– AlexP
Jul 2 at 21:09
It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief.
– traeki
Jul 2 at 21:31
It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief.
– traeki
Jul 2 at 21:31
As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files...
– AlexP
Jul 2 at 23:15
As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files...
– AlexP
Jul 2 at 23:15
|
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
1
down vote
I would suggest turning off the Windows automatic disk optimizer for that disk.
Linux looks at the location on disk as it is journaling, Windows does not.
So even if it changes location by a little bit, to Linux it is not the same anymore.
That should solve your problem!
https://www.top-password.com/blog/disable-automatic-drive-optimization-defrag-in-windows-10/
answered Nov 29 at 17:11
Michael Prokopec
68916
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I would suggest turning off the Windows automatic disk optimizer for that disk.
Linux looks at the location on disk as it is journaling, Windows does not.
So even if it changes location by a little bit, to Linux it is not the same anymore.
That should solve your problem!
https://www.top-password.com/blog/disable-automatic-drive-optimization-defrag-in-windows-10/
answered Nov 29 at 17:11
Michael Prokopec
68916
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
add a comment |
up vote
1
down vote
I would suggest turning off the Windows automatic disk optimizer for that disk.
Linux looks at the location on disk as it is journaling, Windows does not.
So even if it changes location by a little bit, to Linux it is not the same anymore.
That should solve your problem!
https://www.top-password.com/blog/disable-automatic-drive-optimization-defrag-in-windows-10/
answered Nov 29 at 17:11
Michael Prokopec
68916
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
add a comment |
up vote
1
down vote
up vote
1
down vote
I would suggest turning off the Windows automatic disk optimizer for that disk.
Linux looks at the location on disk as it is journaling, Windows does not.
So even if it changes location by a little bit, to Linux it is not the same anymore.
That should solve your problem!
https://www.top-password.com/blog/disable-automatic-drive-optimization-defrag-in-windows-10/
answered Nov 29 at 17:11
Michael Prokopec
68916
I would suggest turning off the Windows automatic disk optimizer for that disk.
Linux looks at the location on disk as it is journaling, Windows does not.
So even if it changes location by a little bit, to Linux it is not the same anymore.
That should solve your problem!
https://www.top-password.com/blog/disable-automatic-drive-optimization-defrag-in-windows-10/
answered Nov 29 at 17:11
Michael Prokopec
68916
answered Nov 29 at 17:11
Michael Prokopec
68916
answered Nov 29 at 17:11
Michael Prokopec
68916
answered Nov 29 at 17:11
Michael Prokopec
68916
68916
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
add a comment |
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
While this sounds like a decent hypothesis, do you have any reason to be particularly confident that this is the issue? This potential solution has some downsides that would be good to avoid if there are other options.
– Catskul
Nov 29 at 18:51
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
I was having roughly that same problem but was not NTFS, doing this stoped the issue. As I said I was not using NTFS, milage may vary.
– Michael Prokopec
yesterday
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f453049%2fsuppress-bypass-file-has-changed-errors-when-editing-cifs-samba-files%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How is the Windows share mounted? Smbfs or cifs?
– AlexP
Jul 2 at 16:19
@AlexP cifs -- here's the /etc/fstab line: //10.0.2.2/netgd /home/jsh/gd cifs credentials=/home/jsh/.smbcredentials,defaults,uid=1000,gid=1000,x-systemd.automount,x-systemd.device-timeout=1,x-systemd.mount-timeout=1
– traeki
Jul 2 at 18:01
This answer (on AskUbuntu) suggests
actimeo=0as a possible solution to the problem of the client and server having a different idea of a file's last modified time. (The optionactimeo=0suppresses caching file metadata such as timestamps.) Note that this will make the SMB protocol somehow even more chatty than it already is.– AlexP
Jul 2 at 21:09
It feels a little more like a "workaround" than a "fix" at some level, since it does slow disk performance perceptibly. But that's WAAAY more tolerable than having to confirm every time I hit :w in vim, which is like 100x/hour. I'd love to get a better handle on why the cifs system is misbehaving and fix that directly, if other folks have insight in that direction, but thank you SO MUCH for a solution to the symptom, @AlexP. HUGE relief.
– traeki
Jul 2 at 21:31
As for the root cause, the documentation of Samba speaks about Windows being somewhat lazy with updating the last modified time of files...
– AlexP
Jul 2 at 23:15