Opened 12 years ago

Closed 10 years ago

#90 closed defect (worksforme)

Editor silently lets you clobber changed file

Reported by: gz Owned by: gb
Priority: major Milestone: Cocoa IDE v1
Component: IDE Version:
Keywords: Cc:

Description

Open a file in the IDE. Open the same file in emacs, make a change, save it. Now make a change in the IDE and save it -- it quietly overwrites the changes you made in emacs. It should notice the change and confirm whether you want to overwrite it

Change History (6)

comment:1 Changed 12 years ago by gb

  • Status changed from new to assigned

When something similar happens and TextEdit? is involved (e.g., open file in TextEdit?, open and modify in Emacs, try to save in TextEdit?), TextEdit? notices that the file's been renamed (to "foo.lisp~" or whatever Emacs renamed the original to while saving).

If the file's externally deleted, trying to save in TextEdit? claims that the document's location can't be determined.

If the file's deleted and then recreated externally, saving in TextEdit? notices that the file's been modified and pops up an alert.

comment:2 Changed 12 years ago by gb

Scarily enough, this seems to work sometimes. (It all should be "free" NSDocument behavior.)

When it works, the document maintains an FSRef to the original pathname. If the file is renamed, the new name is reflected in the window title (and attempts to save the document note this fact and ask for confirmation.)

Whether it works or not may have something to do with how the editor document is created. I've seen it "work" (maintain the FSRef that enables it to detect these kinds of changes) when the document was opened via "Open Recent ..."; I've seen it fail some times as well, and don't yet know what the determining factors are.

comment:3 Changed 12 years ago by gb

Here's a little function that loops over all Hemlock buffers, trying to peek inside the private data structure associated with the buffer's documents that tracks changes to the represented file:

(defun show-tracking-info () 
  (do* ((buffers (cdr hi::*buffer-list*) (cddr buffers)))
     ((null buffers))
  (let* ((doc (hi::buffer-document (car buffers))))
    (when doc
      (format t "~%~%~s~%~s" (car buffers) doc)
      (let* ((info (pref doc :<NSD>ocument._private<D>ata)))
      (loop for i from 2 to 5 do (print (paref info (:* :id) i))))))))

NOTE: I've tried this on PPC32; it may not work on x86-64.

For some buffers, the output looks like:

#<Hemlock Buffer "modeline.lisp /usr/local/src/ccl/cocoa-ide/hemlock/src/">
#<HEMLOCK-EDITOR-DOCUMENT <HemlockEditorDocument: 0x97fa00> (#x97FA00)>
#<NS-OBJECT <NSFileSpecifier: 0x86f440b0> (#x86F440B0)> 
#<NS-OBJECT <NSFileSpecifier: 0x86f44110> (#x86F44110)> 
#<NS-STRING "modeline.lisp" (#x86F44170)> 
#<NS-DATE 2007-08-21 00:07:38 -0600 (#x85AF0670)> 

But for others, it looks like:

#<Hemlock Buffer "lispmode.lisp /usr/local/src/ccl/cocoa-ide/hemlock/src/">
#<HEMLOCK-EDITOR-DOCUMENT <HemlockEditorDocument: 0x91ac00> (#x91AC00)>
#<A Null Foreign Pointer> 
#<A Null Foreign Pointer> 
#<A Null Foreign Pointer> 
#<NS-DATE 2007-08-29 15:30:55 -0600 (#x85AE36F0)> 

The missing NSFileSpecifiers (which I assume are just wrappers around FSSpecs) seem to cause the problem, but I don't know why they're present in some cases but missing in others.

comment:4 Changed 10 years ago by jaj

  • Milestone set to Cocoa IDE v1

Should be fixed for Cocoa IDE v1

comment:5 Changed 10 years ago by gb

I can't reproduce this, and I can certainly reproduce the expected/correct behavior pretty easily. If there's a bug here, it's that the editor "sometimes, for unknown reasons, silently lets you clobber a changed file"; the title of this bug suggests that it always does this.

If this still sometimes happens, it's certainly worth trying to figure out why it happens.

I think that most of the behavior that I ascribed to TextEdit in the first comment above is now shared by the IDE, and I think that this is just standard NSDocument behavior; we don't have to do anything to get that behavior except avoid interfering with it. It's certainly possible that we've done things that interfere with NSDocument's ability to detect external modifications and may still be doing so, but whatever those things are I don't know how to reproduce them.

comment:6 Changed 10 years ago by jaj

  • Resolution set to worksforme
  • Status changed from assigned to closed

Closing bug, until we can come up with a reproduceable test case.

Note: See TracTickets for help on using tickets.