BUG: Saved, Open file becomes Dirty/Unsaved with unmount

[shanebdavis]

If I save a file on a mountable drive, then I unmount/eject it, the file becomes marked as dirty/unsaved. This causes me no end of confusion when I come back later. Did I save it? Or didn't I? I should be able to just close the file and, if it didn't change, not be prompted.

My use case is opening sensitive files from a Truecrypt volume. Truecrypt automatically unmounts after a certain amount of inactivity. The files I open are important, but rarely changed. If, however, I had made a change, it is very important that it be saved. When Sublime lies to me about the state of saving the file, this can be rather stressful - have I saved an important change, or haven't I? Do I need to remount the protected volume and save just in case?

-Shane

[phillip.koebbe]

While I understand and appreciate your frustration, I don't know that this is a bug. I see it in git repos quite frequently: I create a file in one branch and save it, then switch to a different branch where the file does not exist. ST2 still has the file's contents in the buffer, but the underlying file is gone. How can ST2 do anything but consider it a new file? It is definitely something to get used to, but it seems quite logical to me.

[Eduan]

So you mean that if a file is no longer accessible by Sublime Text, it shows it as a dirty file? Even though it no longer exists? If so then this is intended behaviour as far as I'm aware.

- Eduan

[phillip.koebbe]

So you mean that if a file is no longer accessible by Sublime Text, it shows it as a dirty file? Even though it no longer exists? If so then this is intended behaviour as far as I'm aware.

- Eduan

As I understand the behavior, if the file a buffer points to goes away, the contents of the buffer remain but it is treated as a new file since there is no file on disk. It is essentially the same thing as creating a new file, except the path is still associated with the buffer, so if you save, you'll create that same file again. For example,

- Create a new buffer and add some content
- Save it somewhere (~/tmp/bogus_file.txt or something)
- Go delete the file you just saved
- Back in ST2, the buffer will show as unsaved
- Save it (CMD-S on a Mac)
- Go look and the file should be there again

[Eduan]

Yes, I believe this is intended behaviour.

John's gonna have to confirm though, and see if he can add an option for that.

- Eduan

[onetom]

It's pretty sad if this is the intended behaviour.

I don't find it logical either when I delete a file from the side bar, the corresponding window stays open, but goes into unsaved state... I would think it's pretty clear I want the file to go away, still I'm asked if I want to "Save" it, meaning re-create. Why would I want that?

And please don't use git as a (good) example. That's most unintuitive piece of mainstream software on earth. I don't think the in-place branch switching it does is a good idea, exactly because of the mentioned side effects. See http://darcs.net as an alternative way. It just leaves branching to regular file system manipulation tools, which everyone knows well...

I would propose closing the orphaned buffers without questions, IF they are saved.
If they were not saved, warn about the disappearance of the actual file before saving AND also before closing.

[phillip.koebbe]

It's pretty sad if this is the intended behaviour.

You're entitled to your opinion. Software developers make decisions for various reasons, generally knowing they aren't going to be able to please everyone.

I don't find it logical either when I delete a file from the side bar, the corresponding window stays open, but goes into unsaved state... I would think it's pretty clear I want the file to go away, still I'm asked if I want to "Save" it, meaning re-create. Why would I want that?

I agree with deleting a file. If I delete it, I want it to go away. But the file disappearing beneath the application without user intervention *in* the application is beyond the application's control. It seems logical and reasonable (to me anyway) that the only thing the application can do is keep the contents of the buffer. I would be pretty hacked off if the application made a decision such as "Well, the underlying file is no longer there. I don't know why, and I don't really care. Let's just trash the buffer as well." That is *not* what I want an editor to do.

And please don't use git as a (good) example. That's most unintuitive piece of mainstream software on earth. I don't think the in-place branch switching it does is a good idea, exactly because of the mentioned side effects. See http://darcs.net as an alternative way. It just leaves branching to regular file system manipulation tools, which everyone knows well...

This is not the appropriate forum for discussing how SCMs work.

I would propose closing the orphaned buffers without questions, IF they are saved.
If they were not saved, warn about the disappearance of the actual file before saving AND also before closing.

Again, if the user initiated the action *through ST2* that caused the underlying file to disappear, I would agree that closing the buffer is a good idea. But if something happens outside the control of ST2, I don't want my buffers suddenly disappearing. Don't forget that you can put your idea up for vote over at UserEcho [1] and if enough people agree with you, it will bubble to the top and get Jon's attention.

[1] http://sublimetext.userecho.com