What is atomic saving?
How can I tell TextMate to save as soon as it loses focus? Due to I compile some Xcode apps inside Xcode, and use textmate to do all my editing and I keep forgeting to hit Command-S. (unless someone has a more effient way)
Thanks :)
Paul
On 1. feb 2005, at 5:26, Paul Kline wrote:
What is atomic saving?
Atomic saving makes sure that the old version of the file on disk is replaced with the new one in on, atomic, operation. This is sometimes needed when the files you are writing might at the same time be read by other running programs. Technically it's writing the file with another name, then renaming the new file into the old file (destroying the old file in the process).
The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
How can I tell TextMate to save as soon as it loses focus?
I don't think you can do that, currently.
According to Sune Foldager:
The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
The advantage is that with GNU arch/bazaar which use hard-linking to a central revision library (to speed up access and avoid wasting space) you can use TM. When one modifies a given file, in that case you MUST break hard links.
On 1. feb 2005, at 13:08, Ollivier Robert wrote:
According to Sune Foldager:
The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
The advantage is that with GNU arch/bazaar which use hard-linking to a central revision library (to speed up access and avoid wasting space) you can use TM. When one modifies a given file, in that case you MUST break hard links.
Yes, for some it's good that it breaks, for some it's bad :-p.
On 01.02.2005, at 11:57, Sune Foldager wrote:
On 1. feb 2005, at 5:26, Paul Kline wrote:
What is atomic saving?
Atomic saving makes sure that the old version of the file on disk is replaced with the new one in on, atomic, operation. This is sometimes needed when the files you are writing might at the same time be read by other running programs. Technically it's writing the file with another name, then renaming the new file into the old file (destroying the old file in the process).
The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
Apple has been promoting this practice for ten years or more, and aliases have always worked with it in the past. As I understand it, part of the reason for Apple providing a function to do this is specifically so that aliases continue to function. The documentation [1] says that the "file ID" is preserved, though I don't know if that's the same thing as an "inode number."
[1] http://developer.apple.com/documentation/Carbon/Reference/File_Manager/ file_manager/function_group_21.html
On Feb 6, 2005, at 2:42 PM, Ryan Schmidt wrote:
On 01.02.2005, at 11:57, Sune Foldager wrote:
On 1. feb 2005, at 5:26, Paul Kline wrote:
What is atomic saving?
Atomic saving makes sure that the old version of the file on disk is replaced with the new one in on, atomic, operation. This is sometimes needed when the files you are writing might at the same time be read by other running programs. Technically it's writing the file with another name, then renaming the new file into the old file (destroying the old file in the process). The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
Apple has been promoting this practice for ten years or more, and aliases have always worked with it in the past. As I understand it, part of the reason for Apple providing a function to do this is specifically so that aliases continue to function. The documentation [1] says that the "file ID" is preserved, though I don't know if that's the same thing as an "inode number."
Yup, the "atomic save" checkbox could go away, or at least default to "on."
[1] http://developer.apple.com/documentation/Carbon/Reference/ File_Manager/file_manager/function_group_21.html
man exchangedata provides better background information. exchangedata is the core VFS implementation of FSExchangeObject; it may be easier to call from Cocoa.
Chris
On Feb 6, 2005, at 8:09 PM, Chris Thomas wrote:
On Feb 6, 2005, at 2:42 PM, Ryan Schmidt wrote:
On 01.02.2005, at 11:57, Sune Foldager wrote:
On 1. feb 2005, at 5:26, Paul Kline wrote:
What is atomic saving?
Atomic saving makes sure that the old version of the file on disk is replaced with the new one in on, atomic, operation. This is sometimes needed when the files you are writing might at the same time be read by other running programs. Technically it's writing the file with another name, then renaming the new file into the old file (destroying the old file in the process). The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
Apple has been promoting this practice for ten years or more, and aliases have always worked with it in the past. As I understand it, part of the reason for Apple providing a function to do this is specifically so that aliases continue to function. The documentation [1] says that the "file ID" is preserved, though I don't know if that's the same thing as an "inode number."
Yup, the "atomic save" checkbox could go away, or at least default to "on."
[1] http://developer.apple.com/documentation/Carbon/Reference/ File_Manager/file_manager/function_group_21.html
man exchangedata provides better background information. exchangedata is the core VFS implementation of FSExchangeObject; it may be easier to call from Cocoa.
Eh, it occurs to me that man page may not be installed on Panther. Go here instead:
http://developer.apple.com/qa/qa2001/qa1327.html
Chris
On Feb 7, 2005, at 16:13, Sune Foldager wrote:
Yup, the "atomic save" checkbox could go away, or at least default to "on."
No it shouldn't go away; some people don't need the atomicity and don't want their hard-links broken.
Also, it causes the icon to be re-arranged in Finder when the file is saved using the 'atomically' version provided by Cocoa, and it fails if the user has no write access to the directory (but only the file).
On 7. feb 2005, at 17:30, Allan Odgaard wrote:
On Feb 7, 2005, at 16:13, Sune Foldager wrote:
Yup, the "atomic save" checkbox could go away, or at least default to "on."
No it shouldn't go away; some people don't need the atomicity and don't want their hard-links broken.
Also, it causes the icon to be re-arranged in Finder when the file is saved using the 'atomically' version provided by Cocoa, and it fails if the user has no write access to the directory (but only the file).
Exactly a good reason not to ditch the setting; Obviously, Cocoa and Finder have some issues with eachother at times, and this is another one. Especially tricky is the case (which probably rarely happens except on remote drives) where you have +w on the file but not on its directory. I believe TM will fall back to non-atomic writes in this case?
On 6. feb 2005, at 23:42, Ryan Schmidt wrote:
On 01.02.2005, at 11:57, Sune Foldager wrote:
The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
Apple has been promoting this practice for ten years or more, and aliases have always worked with it in the past.
Yes, because aliases check location first, inode second (used to be the other way around in OS9-). So yes, atomic saves in this fashion will not break aliases, but will break hard links of course. Symbolic links are also untouched.
As I understand it, part of the reason for Apple providing a function to do this is specifically so that aliases continue to function.
Well... Apple's function does it the same way as I described, which is also what their doc says. This has been a pretty standard way for a long time also on UNIX. Of course abstraction is always good, and who knows, maybe sometime the file system might support atomic saves directly. Incidentally that would pose a problem since now you can be _sure_ atomic saves break hard links, but you can't otherwise. Then a system function to break a hard link might be needed.
The documentation [1] says that the "file ID" is preserved, though I don't know if that's the same thing as an "inode number."
Well it can't be since inodes are not preserved by atomic saves in this fashion.
On Feb 7, 2005, at 7:12 AM, Sune Foldager wrote:
On 6. feb 2005, at 23:42, Ryan Schmidt wrote:
On 01.02.2005, at 11:57, Sune Foldager wrote:
The disadvantage of atomic saves (for some), is that the file gets a new inode-number each time which will break hard-links and might upset aliases if they are not pointing correctly.
Apple has been promoting this practice for ten years or more, and aliases have always worked with it in the past.
Yes, because aliases check location first, inode second (used to be the other way around in OS9-). So yes, atomic saves in this fashion will not break aliases, but will break hard links of course. Symbolic links are also untouched.
Aliases store the file ID on HFS volumes. The change to alias resolution ordering was a user interface decision -- if I have an alias to a copy of TextMate, and I throw out the copy of TextMate, and place a new copy of TextMate in the location of the old TextMate, I might reasonably want the alias to point to the new copy of TextMate, rather than the old one in the Trash.
However, it appears that this discussion is academic, because HFS+'s implementation of exchangedata actually returns an error if one of the files is hardlinked.
Chris
On 7. feb 2005, at 18:29, Chris Thomas wrote:
However, it appears that this discussion is academic, because HFS+'s implementation of exchangedata actually returns an error if one of the files is hardlinked.
Huh? If I have file A hard linked with B and I "atomically" replace A (i.e. write A.new, move A.new to A) then I will break the link between A and B. That's the issue here, and that's certainly what happens in the scenario I just described :-). No HFS+ errors here.
On Feb 8, 2005, at 9:00 AM, Sune Foldager wrote:
On 7. feb 2005, at 18:29, Chris Thomas wrote:
However, it appears that this discussion is academic, because HFS+'s implementation of exchangedata actually returns an error if one of the files is hardlinked.
Huh? If I have file A hard linked with B and I "atomically" replace A (i.e. write A.new, move A.new to A) then I will break the link between A and B. That's the issue here, and that's certainly what happens in the scenario I just described :-). No HFS+ errors here.
Right, but I'm talking specifically about the exchangedata system call (or FSExchangeObjects). exchangedata is a Darwin VFS operation. It calls into the file system implementation to perform the atomic exchange. For HFS+, it explicitly preserves the file ID. I had assumed it would preserve hardlinks as well, but it turns out that it just errors out if one of the files is hardlinked (or has ever been hardlinked).
Chris
On 8. feb 2005, at 18:43, Chris Thomas wrote:
Huh? If I have file A hard linked with B and I "atomically" replace A (i.e. write A.new, move A.new to A) then I will break the link between A and B. That's the issue here, and that's certainly what happens in the scenario I just described :-). No HFS+ errors here.
Right, but I'm talking specifically about the exchangedata system call (or FSExchangeObjects). exchangedata is a Darwin VFS operation. It calls into the file system implementation to perform the atomic exchange. For HFS+, it explicitly preserves the file ID. I had assumed it would preserve hardlinks as well, but it turns out that it just errors out if one of the files is hardlinked (or has ever been hardlinked).
I see... interesting. Of course somewhat unfortunate that it fails with multilinked files.... then, preserving the id/inode will only help with alises (if the file was moved since the alias was created).
-
Allan Odgaard -
Chris Thomas -
Ollivier Robert -
Paul Kline -
Ryan Schmidt -
Sune Foldager