Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emacs incorrectly warns about external modification when syncing in background. #446

Closed
thblt opened this issue Sep 17, 2016 · 12 comments
Closed
Labels

Comments

@thblt
Copy link

thblt commented Sep 17, 2016

When cozy-desktop sync is running and I work on a file in the Cozy directory, Emacs (24.5.1, latest packaged version, ArchLinux) keeps issuing warnings that the file has been externaly modified. This seems to happen after each Emacs save (which happens often).

Something just a little bit weird seems to be happening with timestamps and Emacs doesn't like it at all. I made the following test:

  • Kill (nicely) cozy-desktop

  • Modify a file in emacs.

  • stat the file:

    Accès : 2016-09-17 18:15:41.113809425 +0200
    Modif. : 2016-09-17 18:15:41.113809425 +0200
    Changt : 2016-09-17 18:15:41.120475957 +0200
    Créé : -
    
  • Run cozy-desktop sync again, wait until the file gets synced, kill it (nicely)

  • Restat:

    Accès : 2016-09-17 18:16:41.315920663 +0200
    Modif. : 2016-09-17 18:15:41.000000000 +0200
    Changt : 2016-09-17 18:16:40.305941165 +0200
    Créé : -
    
@thblt
Copy link
Author

thblt commented Sep 17, 2016

(notice how all timestamps are different after the sync, when only atime should be)

@thblt
Copy link
Author

thblt commented Sep 17, 2016

Sorry for spamming, another precision. I tried with an innocent file Emacs never touched. I created it (echo something > test), stat, sync, stat, modified it, stat, sync, stat. The 4 stat outputs are:

# File just created
 Accès : 2016-09-17 18:29:51.973203695 +0200
Modif. : 2016-09-17 18:29:51.973203695 +0200
Changt : 2016-09-17 18:29:51.973203695 +0200
  Créé : -

# After initial sync
 Accès : 2016-09-17 18:30:15.419394405 +0200
Modif. : 2016-09-17 18:29:51.973203695 +0200
Changt : 2016-09-17 18:29:51.973203695 +0200
  Créé : -

# Modified
 Accès : 2016-09-17 18:30:15.419394405 +0200
Modif. : 2016-09-17 18:31:24.244663923 +0200
Changt : 2016-09-17 18:31:24.244663923 +0200
  Créé : -

# After second sync
 Accès : 2016-09-17 18:31:35.014445297 +0200
Modif. : 2016-09-17 18:31:24.000000000 +0200
Changt : 2016-09-17 18:31:34.004465799 +0200
  Créé : -

(Notice how every time, the fourth part of the mtime (nanoseconds? idk) gets set to 0)

@nono
Copy link
Member

nono commented Sep 19, 2016

Hi,

thanks for the bug report.

(Notice how every time, the fourth part of the mtime (nanoseconds? idk) gets set to 0)

Cozy-desktop keeps the time with only a precision of a second.

@thblt
Copy link
Author

thblt commented Nov 22, 2016

Until this is fixed on Cozy side, Emacs users may find the snippet below to be useful. Simply yank [=paste] it somewhere in your init.el and Emacs will insure the buffer actually differs from its underlying file's contents before marking it as externally modified.

It comes from this StackOverflow answer.

;; Ignore modification-time-only changes in files, i.e. ones that
;; don't really change the contents.  This happens often with
;; switching between different VC buffers.

(defun update-buffer-modtime-if-byte-identical ()
  (let* ((size      (buffer-size))
         (byte-size (position-bytes size))
         (filename  buffer-file-name))
    (when (and byte-size (<= size 1000000))
      (let* ((attributes (file-attributes filename))
             (file-size  (nth 7 attributes)))
        (when (and file-size
                   (= file-size byte-size)
                   (string= (buffer-substring-no-properties 1 (1+ size))
                            (with-temp-buffer
                              (insert-file-contents filename)
                              (buffer-string))))
          (set-visited-file-modtime (nth 5 attributes))
          t)))))

(defun verify-visited-file-modtime--ignore-byte-identical (original &optional buffer)
  (or (funcall original buffer)
      (with-current-buffer buffer
        (update-buffer-modtime-if-byte-identical))))
(advice-add 'verify-visited-file-modtime :around #'verify-visited-file-modtime--ignore-byte-identical)

(defun ask-user-about-supersession-threat--ignore-byte-identical (original &rest arguments)
  (unless (update-buffer-modtime-if-byte-identical)
    (apply original arguments)))
(advice-add 'ask-user-about-supersession-threat :around #'ask-user-about-supersession-threat--ignore-byte-identical)

@sebn
Copy link
Contributor

sebn commented Jan 3, 2017

Hello there!
Sorry for the late answer.

Are you still getting this issue? With the same Emacs version and latest up-to-date Arch? And which cozy-desktop version are you using?

Thank you!

@thblt
Copy link
Author

thblt commented Jan 3, 2017

Hello sebn,

I've stopped using Cozy to manage most of my work files and reverted to a Git-based process, since Cozy desktop was getting really unstable with my increasingly large work folders (and even with regular versioned backups, it was getting a bit frightening). (I haven't filed bugs because I really don't have time to try and reproduce seemingly random behavior, sorry about that. Tell me if you're interested in more details :-)

Re the current bug, I see no commit referencing it. If the probable cause of the problem (dropping nanoseconds when setting back the mtime) has been addressed, I can try to see if the problem with Emacs is solved. If not, I can still try, but I don't believe in magic :-)

@sebn
Copy link
Contributor

sebn commented Jan 3, 2017

Well, I don't think the time precision issue was adressed, so you're probably right: no magic here :)

Thank you for giving it a try, anyway. The project should be more active during the upcoming months, with more platforms supported, and hopefully more bugs fixed. I'll keep this issue open and try to reproduce/fix it as soon as possible.

@thblt
Copy link
Author

thblt commented Jan 3, 2017

Thank you for giving it a try, anyway.

OK, I'll do it when I have time. Can't promise it will be soon though.

@sebn
Copy link
Contributor

sebn commented Jan 5, 2017

I meant "giving it a try in the past", I didn't expect you to test it forever when you don't use it anymore :)

Since this issue is part of the known limitations of cozy-desktop, and we have tons of work to do, it's not really in the top list, so I can't promise either I'll fix it soon. I'll comment here when I can work on it.

@thblt
Copy link
Author

thblt commented Jan 5, 2017

Since this issue is part of the known limitations of cozy-desktop

In fact, it is not listed in the section you linked :-) Adding it with a link to the Emacs workaround would be nice.

(I also noticed two typos in this section: "a reasonable size for files (< 1 To)" should be "1 Tb"; "git and other VCS are not meant to be share like this" should be something like "git (and other VCS) repositories are not meant to be shared this way")

@sebn
Copy link
Contributor

sebn commented Jan 5, 2017

Agreed. Fixed on master. Thanks!

@sebn
Copy link
Contributor

sebn commented Aug 17, 2018

Hello there!

Stopping the app (3.9.0) and editing a file offline in emacs:

$ stat emacs.txt
...
 Accès : 2018-08-17 09:14:00.441933876 +0200
Modif. : 2018-08-17 09:14:00.441933876 +0200
Changt : 2018-08-17 09:14:00.449934074 +0200

Then after restart/syncing:

$ stat emacs.txt
...
 Accès : 2018-08-17 09:14:31.521702683 +0200
Modif. : 2018-08-17 09:14:00.441933876 +0200
Changt : 2018-08-17 09:14:00.449934074 +0200

So mtime/ctime are not modified anymore while the file is still synced correctly.

Editing the file while the app is synching in the background, I don't get any background modification warning, so I assume the issue is fixed.

Closing, feel free to reopen in case it doesn't work for you.
And sorry for the delay (I believe it was actually fixed a few months ago but not in order to fix this issue precisely, so we forgot to update it, sorry again).

@sebn sebn closed this as completed Aug 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants