3

The issue

While (in this case) editing a .css file in Bluefish, I am switching to the browser to reload the page and test the result. After that, I switch back to the .css file, and get the message that "the (.css) file was edited on disk".

enter image description here

I am pretty sure it wasn't me, editing the file from another application.
This is constantly happening, if it happens, which is not always. When it starts, it is unstopable.

No Bluefish issue

Since it is not only with Bluefish, but similarly when writing e.g. a bash script in gedit, the "edit", must be real. In the file nothing is actually changed however.

Note

I am editing the files on a NAS, locally linked on my desktop.

Community
  • 1
Jacob Vlijm
  • 82,471
  • 12
  • 195
  • 299
  • Maybe because the access time changed in the files stats, try a `stat filename` if this causes the same behavior. – Videonauth May 22 '16 at 08:14
  • 1
    @Videonauth yeah, I am pretty sure that happens, but what is it caused by? – Jacob Vlijm May 22 '16 at 08:15
  • When the file is shown on server it gets loaded and therefore the access time possibly changed, this will cause a change in the files checksum, and on the long run makes your editor believe the file has changed. – Videonauth May 22 '16 at 08:17
  • @Videonauth Waitwait you might have a point there, I moved the files to a NAS, linked on my desktop. will try to copy it locally, see if that havppens then as well... – Jacob Vlijm May 22 '16 at 08:19
  • @Videonauth and it doesn't!! If you produce an answer, I'll accept :) great. – Jacob Vlijm May 22 '16 at 08:25
  • uuuuhhmm... a downvote? please explain. – Jacob Vlijm May 22 '16 at 13:04

1 Answers1

7

As we discussed in comments and found out that the files are on a NAS, testing the files does in fact read them and causes a change in their access time stat as you can see with:

stat <filename>

As this is part of the file itself it therefore changes the files checksum and makes your editor believe that the file has been changed.

Videonauth
  • 33,045
  • 16
  • 104
  • 120
  • 2
    The solution is to reconfigure the FS to not take metadata-access as writing, or to use an arg to `stat` that doesn't clobber on read. – cat May 22 '16 at 12:41
  • Sorry, how is the `stat` command exaclty telling us about the issue? Should one see that the Access field has a very recent date? Thanks! – Matifou Sep 18 '17 at 22:53
  • I think the ideas is when you observe the issue, if you then look at stat for the file, you will verify there is a new access time that coincides with the error. So @cat, how do you reconfigure the FS not to take metadata-access as writing? – Jai Jeffryes Aug 22 '22 at 16:17