Mac OSX Deletes Open Documents
Astoundingly fucked up, yet true. I just got an email from a client who said she'd accidentally deleted a file she had open, and when she closed said document it was gone. I was all set to email her back saying that her file could not have been deleted if it was open, because the Mac OS won't allow that sort of thing, but I thought I'd try it first, just to make sure I wasn't talking out my ass (which is something you learn to do after many years in systems work — try stuff before you speak, that is, not talk out your ass, though that does come with the territory as well I suppose.)
So I tried it. I opened up DVD Studio Pro, created a new document, saved it to the Desktop, and then — with the document still open, mind you — I deleted it. Put it in the trash and deleted it. I received no warning message. And when I quit DVDSP, I was not prompted to re-save the document. It was gone, daddy, gone.
As astoundingly fucked up as this is, I do understand exactly why this happens. You see, active documents — that is, documents which are currently open — are stored in a temporary location, not, as one might suspect, where they are saved. The saved document and the open document are two separate files. Each application determines where the temporary storage location for open files will be. In the case of Final Cut docs, for example (and I know this from cold, hard experience), the temporary storage location is in a folder called .TemporaryItems on whatever drive is the active working drive. So, since the saved file and the active file are actually separate, it's very possible to apparently delete a file that's open in an application, because the file you're deleting is not the open file you're currently working on. It's a saved version.
I don't know if I mentioned that this is fucked up, but it really is. Astoundingly so.
In the same way that you can't delete running processes, I think Apple really needs to make it equally impossible (or at least as difficult) to delete active files. The current paradigm just doesn't make any kind of sense from where I sit.
UPDATE:
A reader has pointed out in the comments that one application actually works the way you might expect. That application is Microsoft Word. A saved Word document and an open Word document are (apparently) one-and-the-same, and Word is able to keep track of open files even when they're moved. If the fact that Word behaves more sensibly than most Apple applications isn't an indication that this is something that needs fixin', I'm not sure what is.
So I tried it. I opened up DVD Studio Pro, created a new document, saved it to the Desktop, and then — with the document still open, mind you — I deleted it. Put it in the trash and deleted it. I received no warning message. And when I quit DVDSP, I was not prompted to re-save the document. It was gone, daddy, gone.
As astoundingly fucked up as this is, I do understand exactly why this happens. You see, active documents — that is, documents which are currently open — are stored in a temporary location, not, as one might suspect, where they are saved. The saved document and the open document are two separate files. Each application determines where the temporary storage location for open files will be. In the case of Final Cut docs, for example (and I know this from cold, hard experience), the temporary storage location is in a folder called .TemporaryItems on whatever drive is the active working drive. So, since the saved file and the active file are actually separate, it's very possible to apparently delete a file that's open in an application, because the file you're deleting is not the open file you're currently working on. It's a saved version.
I don't know if I mentioned that this is fucked up, but it really is. Astoundingly so.
In the same way that you can't delete running processes, I think Apple really needs to make it equally impossible (or at least as difficult) to delete active files. The current paradigm just doesn't make any kind of sense from where I sit.
UPDATE:
A reader has pointed out in the comments that one application actually works the way you might expect. That application is Microsoft Word. A saved Word document and an open Word document are (apparently) one-and-the-same, and Word is able to keep track of open files even when they're moved. If the fact that Word behaves more sensibly than most Apple applications isn't an indication that this is something that needs fixin', I'm not sure what is.
This entry was posted
on Wednesday, February 01, 2006 at 6:31 PM.
You can skip to the end and leave a response.
7:43 PMThis seems to be app-dependent. I created a file in TextEdit and saved it to the desktop. I made some changes and dragged the unsaved file to the Trash. When I tried to close the file TextEdit prompted me if I wanted to save changes; when I accepted, it saved the file onto the Desktop (while the old file remained in the Trash). I also tried emptying the trash and had the same results.
I repeated the test with BBEdit, Excel and Word. BBEdit and Excel acted the same as TextEdit.
Word, on the other hand, acted as you describe. Sort of. I created a new file, saved it, made some changes and trashed the (unsaved) file. When I tried to empty the trash the Finder gave a "file in use" error, which it should (and should have done with TextEdit and BBEdit). If I left the file in the trash and tried to close the file, clicking the Save button on the "do you want to save changes" dialog did nothing -- no file on the desktop.
9:52 PM
Well, yeah, that's exactly right. If you haven't saved the document, almost any app will prompt you to save it, and when you do you create a new document from the temporary (open) document. Try just saving the document, then deleting it and closing the app (which is what my client apparently did) and you'll see what I mean. Bye, bye document.
Yes, it definitely is application-specific. In fact, the temporary location where open files are stored is completely determined by the application (FCP uses one location, mentioned in my article, Macromedia apps use another similarly named one in the user's home account, according to their website). It looks like Microsoft Word actually is doing what I would consider to be the right thing, which is, once a file is saved, there is no "temporary file." The saved file is the active, open file. So, of course, once it's been moved to the trash you can't delete it because it's in use, nor can you save it because the file path has changed without alerting the application. You should still be able to "Save As.." though. So the Microsoft way is less potentially destructive.
Go figure...
Actually, I just tried this myself (that talkin' out my ass business again) in Word v.11.2.0. My version of Word behaves perfectly. I work on the file, I move it to the trash, but I cannot delete it. If I continue to make changes to the doc, the changes can be saved to the trashed file. Quitting Word and reopening the trashed modified files show that the changes were saved even though the file was in the trash.
Gotta say MS Word has got it all over Apple apps in this regard. Which just proves my original point: Apple should fix this.
The basic problem with other apps is that the saved file and the open file are two different files. So changes to the file on, say, the Desktop — changes like deletions, for instance — aren't seen by the application via the currently open doc. And that, as I believe I said, is fucked up.
Ideally, even if apps need to store files in a temp location they would keep better track of their files, but at least in the Microsoft scheme, the open file and the saved file are one and the same, and that just makes a lot more sense to me. And it works better.
12:01 PM
Word works great except when some bright bulb opens the document from the server. It looks like the location of the temp file isn't consistent with where Word wants to store the file, i.e. locally. Users should move the file to their computer, work on it then put it back on the server to be safe.
9:31 PM
Yup... We've had silmilar problems with our network home accounts...
Good times...
-systemsboy
11:39 AM
Actually, this is how it's supposed to work. Unix filesystems keep track of 2 different things: how many processes have the file open, and how many references to the file there on in the directory structures. (i.e. a file with an additional hard link pointing at it will have a file-reference count of 2.) It's only when both hit zero that the underlying blocks are marked as free.
Windows doesn't keep track of the number of processes that have the file open -- it just locks the file. (And if some process fails to close an open file, you'll never be able to delete it.)
There are quite a number of reasons why the Unix way is safer / saner.
The apps that you're seeing it work with are likely using different logic to determine if the on-disk copy is old/missing; and it's certainly better logic. But the underlying semantics are absolutely correct.
3:44 PM
Really, this is not an issue of whether or not the OS is allowing you to delete open files. Mac OSX does not allow the deletion of open files. Open files, to the best of my knowledge, are handled by the UNIX layer just as you describe. This is not an issue of logic or semantics. This is an issue of presentation. Some applications conspire with the OS to present any given open file as the same file that is saved on disk, when in fact, they are two different files. This is the key here, so I'll say it again one last time: THE OPEN FILE AND THE SAVED FILE ARE ACTUALLY TWO DIFFERENT FILES. This discrepancy between what you see and what is actually the case can lead to data loss, as detailed in the article. Whether or not the logic or the semantics are sound is irrelevant. It's a problem.
-systemsboy
5:59 PM
Quote: This is the key here, so I'll say it again one last time: THE OPEN FILE AND THE SAVED FILE ARE ACTUALLY TWO DIFFERENT FILES.
This simply is not true, and for applications where it is true (TextEdit.app seems to be one...), they're misbehaving as far as the unix world is concerned.
Open files that behave like this are not open files at all, but buffers in the emacs sense of the word buffer. e.g. "You're working on a buffered copy of the file foobar.txt, NOT the file foobar.txt itself!"
As anonymous said, this is the way it works in unix. Unix operating systems have always drawn a distinction between open file descriptors, which you can think of as "the data" and references to the data, namely "filenames."
As a unix admin, I frequently create a file, write a bunch of data into it, reopen it for reading and then immediately unlink the filename from it's data by saying "rm foobar.txt"
When I delete the file, all I'm really doing is **unlinking** the relationship between filename and data. The data is still there, and my program is still holding it open and reading it. Unix kernels are intelligent enough to realize that I'm reading the data and won't reuse those blocks until all file descriptors for that data are closed.
This is how undelete works, by relinking data to filenames, and it's also how I can download 4 gigs of data from a webserver even though I "deleted" the file the day before.
There aren't multiple files at all, there's simply references to blocks of data which are called filenames. Programs can, and should happily work with their data without regard to the named references to that data and what happens to those references while the process writes it's data.
"Delete" is nothing more than a unix rename of the file. Delete simply updates the parent directory of the filename to that of the Trash directory and doesn't touch the data. Remove, or rm, simply unlinks the reference between filename and data. Open files should still behave as if nothing happend when you mv or rm a file.
If anything, what you ask for goes against established Unix conventions...
-Jeff McCune
7:06 PM
This simply is not true, and for applications where it is true (TextEdit.app seems to be one...), they're misbehaving as far as the unix world is concerned.
Jeff,
This is exactly what I'm saying. (Maybe I should change the title to read "Some Applications Allow Deletion of Open Documents.") And there are a lot of apps that are misbehaving in this way: TextEdit, Final Cut Pro, DVD Studio Pro, etc, etc, ad infinitum.
Open files that behave like this are not open files at all, but buffers in the emacs sense of the word buffer. e.g. "You're working on a buffered copy of the file foobar.txt, NOT the file foobar.txt itself!"
Right, a copy or, as I said forty-seven million times now, two different files.
When I delete the file, all I'm really doing is **unlinking** the relationship between filename and data. The data is still there, and my program is still holding it open and reading it. Unix kernels are intelligent enough to realize that I'm reading the data and won't reuse those blocks until all file descriptors for that data are closed.
But when you quit your program, what does it do with the data it's been holding in the buffer? Does it just delete it? Forget about it? Clear the buffer? Or does it ask you to save it? 'Cause part of what I'm arguing is that it should ask you to save the buffered data if there's no longer a reference to it on disk. And that goes double if your program is a Mac OSX GUI application that's pretty likely to be used by folks who aren't UNIX admins. This is not a problem with the UNIX kernel, it's a problem with Mac apps.
This is how undelete works, by relinking data to filenames, and it's also how I can download 4 gigs of data from a webserver even though I "deleted" the file the day before.
I would kill to know how you do this. (I'm not being sarcastic.) I've never found a way to undelete files after an rm (at least not on a Mac. Doesn't undelete require a certain type of filesystem?) Please elaborate, if you would be so kind.
"Delete" is nothing more than a unix rename of the file. Delete simply updates the parent directory of the filename to that of the Trash directory and doesn't touch the data. Remove, or rm, simply unlinks the reference between filename and data. Open files should still behave as if nothing happend when you mv or rm a file.
If anything, what you ask for goes against established Unix conventions...
I think what I'm asking for is right in line with UNIX conventions, but maybe not. Maybe I'm being dreadfully unclear (yes, it would appear so), but what I mean to be asking for is exactly what you say here, but it is not how many/most Mac applications currently behave. I want to be able to:
1) Open a document in an application
2) Save the document to disk
3) Delete the saved file from disk (by moving it to the trash and then emptying the trash)
4) Quit the application with the open document
5) Upon quitting the application with the open document, get prompted to save my open document
Unfortunately, the way things work now, when we get to step 5, the application simply quits — never asking to save the document — and all that buffered data that was my document is now, effectively gone. As you say, this is how it works in TextEdit, and I'm telling you, this is how it works in a lot of applications on the Mac, and I've now seen people lose data from this behavior. I think we essentially agree on all of this, and the problem here may be that my original article and some of my comments are not very clear.
Let me restate: I don't think, from a user interface standpoint (not a UNIX admin standpoint) that a user should be able to delete an "open" file (i.e. a file that is, or appears to the user to be, currently open in a running application). Or, if a user is permitted to delete an "open" file (and I assure you, most users see this "open" file and the file they just saved to the Desktop as one and the same), they should at the very least be prompted by the open application to save the "open" file if the one on disk has been deleted.
Maybe you, as a UNIX admin, understand that the file you just saved and the file you have open are separate, distinct entities (one a reference to data on disk, one a store of data in a buffer), but most people don't see it that way. Most people see that file on the Desktop and the one in TextEdit as one in the same, because that's how it's presented to them. So to these users it shouldn't be possible to delete the file they have open in TextEdit. It defies the logic of the Desktop metaphor. And when they are allowed to do this, and lose data because of it, the Desktop metaphor breaks down, and it's a problem.
-systemsboy
» Post a Comment