About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Home » Learning Curve » Hotspots

(A Document Being Saved By Rixedit)/Untitled

One wonders if they realise it's not Unix - or intelligent - anymore.

Buy It

Try It

The perplexing nature of Cocoa I/O under Leopard has long been documented at this site.

A remaining issue was whether the atomically: argument to Cocoa I/O actually did anything.

A test console mode application was created to see if the argument had in fact any effect. Each of the Cocoa classes with I/O APIs with an atomically: argument were tested, using stack instances to write directly to disk.

The ~/Documents directory was monitored with Xfile set to demand inode equality to retain selection through refreshes. The program was run multiple times to detect inode 'bumping'.

The results were not what was expected: the inodes for the writes without 'atomically:' set did not bump their inodes. The files were actually written to - and not obliterated as Leopard is wont to do.

The following code can be incorporated into a standard (Unix) tool project using the Cocoa framework.

#import <Cocoa/Cocoa.h>

int main() {
   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

   [[NSArray array] writeToFile:
        [@"~/Documents/NSArray-0.rtx" stringByExpandingTildeInPath] atomically:0];
   [[NSArray array] writeToFile:
        [@"~/Documents/NSArray-1.rtx" stringByExpandingTildeInPath] atomically:1];

   [[NSData data] writeToFile:
        [@"~/Documents/NSData-0.rtx" stringByExpandingTildeInPath] atomically:0];
   [[NSData data] writeToFile:
        [@"~/Documents/NSData-1.rtx" stringByExpandingTildeInPath] atomically:1];

   [[NSDictionary dictionary] writeToFile:
        [@"~/Documents/NSDictionary-0.rtx" stringByExpandingTildeInPath] atomically:0];
   [[NSDictionary dictionary] writeToFile:
        [@"~/Documents/NSDictionary-1.rtx" stringByExpandingTildeInPath] atomically:1];

   [[NSString string] writeToFile:
        [@"~/Documents/NSString(old)-0.rtx" stringByExpandingTildeInPath] atomically:0];
   [[NSString string] writeToFile:
        [@"~/Documents/NSString(old)-1.rtx" stringByExpandingTildeInPath] atomically:1];

   [[NSString string] writeToFile:
        [@"~/Documents/NSString(new)-0.rtx" stringByExpandingTildeInPath] atomically:0 encoding:4 error:0];
   [[NSString string] writeToFile:
        [@"~/Documents/NSString(new)-1.rtx" stringByExpandingTildeInPath] atomically:1 encoding:4 error:0];

   [pool release]; return 0;

The next step was to see what could be found with standard ACP applications such as Rixedit. If the APIs were working correctly - as before with previous versions of the frameworks - what then had happened with Leopard?

The way to find this was to intercept the 'writeToFile:' method sent by NSDocumentController to the client (NSDocument subclass) and display the actual file path being sent. Was it in fact the actual file to be written to?


It's so cute. It's also bonkers and it trashes file systems.

Somebody in Cupertino needs to get their head examined before the few disillusioned enterprise clients that remain organise a class action.

See Also
Hotspots: Leopard -Tmp-
Developers Workshop: Y.G.B.K.
Hotspots: Just An Ordinary Innocent Little Old Text File
Rixstep/7: '(A Document Being Saved By Rixedit)/Untitled' (Membership Required)

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.