Detect when file on disk is moved/removed and warn about it

[levsa]

Current behaviour when a file that is opened in sublime is moved on disk is that the buffer is marked as having changes to be saved, and when closing sublime warns about saving the file. This is different from when a file is moved or removed (e.g. when changing git branches or whatever) and it is misleading that sublime warns about file not being saved. It should instead warn that the file was moved or removed.

[keith-hall]

possible duplicate of #73

[chrisfcarroll]

[Except on MacOS, it should seamlessly behave as other applications do : https://github.com//issues/2391 ]

[UltraInstinct05]

As of build 4108, Sublime Text shows a different indicator (red) on the tab for deleted files & the confirmation dialog when you try to close it is also updated to show the file is deleted. I guess when you move files from one directory to another, it's considered deleted from the former directory.

[deathaxe]

Not sure about it. Ideally ST would detect renamed files via file system notifications and adjust its catalog and retarget views without any notification needed. No matter wheter a file was renamed/moved or deleted. The only indication ST shows is that it can't find the file anymore and asks to save it again. I guess that's what this issue complains about.

[alberti42]

This issue was raised several times in the history of Sublime and never addressed for many years; see for example this post. Sublime should create an NSURL (see Apple doc page) representation of the opened file. It should be fairly straightforward to find out the new location once Sublime detects that the file has been deleted/moved/renamed (e.g., see this post).

Is there any chance that this will be included in one of the next versions of Sublime? Alternatively, it would be truly great if someone with experience in coding Sublime plugins provided such a solution. One can in principle interface with NSObject and cocoa using Python package pyobjc.

[deathaxe]

Note Sublime Text being a cross-platform editor, so "just" relying on some Apple APIs is not sufficient.

That said, it should already be possible to re-target views to new file locations, as ST uses OS's filesystem notifications to track external changes/movements/deletions/... .

The challange however might be how to handle situations in which external file is moved and modified, while unsaved changes exist in a view with users expecting to not loose either one.

[alberti42]

The challenge, however, may be how to handle situations where an external file is moved and modified while unsaved changes exist in a view where users expect to lose neither.

Thanks for the feedback and your thoughts!

1. In my opinion this should not be a problem. When you move a file, from the point of view of native MacOS applications, it has no direct effect on the file itself. In the sense that once the file is open, the application maintains a link to the file which cannot be broken by simply moving the file to another location. I think this relies on some lower level description of the file's location in the file system in MacOS.

However, it may take some time and skill to implement such file handling in Sublime, so to take advantage of MacOS features. One should probably avoid trying to hack a solution, as it would probably not be very robust.

2. As for changing the content, your point is well taken. But the same thing is already happening. If you change the content with a third party editor and then save, and at the same time make changes in Sublime Text Editor, I believe Sublime now displays a prompt asking if you want to load the latest changes and discard your changes, or keep your changes. So this part does not need to change. And I think ST's behaviour in this respect is already quite satisfactory.