• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Tracking files the right way
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tracking files the right way


  • Subject: Re: Tracking files the right way
  • From: Malte Tancred <email@hidden>
  • Date: Fri, 30 Aug 2002 11:16:06 +0200

On fredag, aug 30, 2002, at 02:47 Europe/Stockholm, Chris Hanson wrote:
At 5:47 PM -0400 8/29/02, Bill Bumgarner wrote:
It is occasionally very handy that an app like IB, TextEdit, emacs, etc... saves the last version as a backup version (i.e. edit 'foo.txt', click 'save', TE moves the current file to foo~.txt and saves the new content to foo.txt).

This is a bug in either TextEdit or Cocoa. TextEdit should save the new content to foo~.txt, and then atomically swap the directory entries for foo.txt and foo~.txt using FSExchangeObjects. This will preserve the file ID of foo.txt, which is how the alias tracks it.

What if the app crash before FSExchangeObjects is called? You'll be stuck with the original content in foo.txt and the updated content in foo~.txt.

If I want to edit a file "the unix way" I make a copy of it, say foo.txt-new, edit the copy, then mv foo.txt-new foo.txt. The save is atomic. If I want a backup I'd copy foo.txt to foo~.txt at an appropriate time. Perhaps somthing like this:

1) copy foo.txt to foo.txt-new
2) copy foo.txt-new to foo~.txt
3) edit foo.txt-new
4) rename foo.txt-new foo.txt

If the system crash at any time during these operations I'd know where to begin when the system is up and running again. The original data will never get lost.

This solution relies on the file names communicating what have been done. The former example - using FSExchangeObjects - could perhaps look at the dates of the files to see that foo~.txt is actually newer than foo.txt, and by that deduce that the app crashed before the save was completed.

Just a few thoughts.

FSExchangeObjects won't work on all volume types, unfortunately, but it will work on HFS+ and AppleShare mounts. On the other hand, on those volume types where it doesn't work, file IDs also aren't supported, so aliases to files on those volumes will probably wind up using full paths and doing what you expect. (If they don't, it means Carbon is probably synthesizing file IDs or something behind your back.)

The correct process for a safe save on a volume that doesn't support FSExchangeObjects is to write the new content to foo~.txt, rename the old file to some temporary name, rename foo~.txt to foo.txt, and rename the temporary name to foo.txt.

Uhm, no, this would trash the new data, ie the last rename of the temporary file (the original content) to foo.txt. :-)

Also, the original data should be left intact for as long as possible, ie no need to rename the old file to some temporary name.

Cheerio,
Malte
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Tracking files the right way
      • From: Chris Hanson <email@hidden>
    • Re: Tracking files the right way
      • From: Rosyna <email@hidden>
References: 
 >Re: Tracking files the right way (From: Chris Hanson <email@hidden>)

  • Prev by Date: Re: Deactivating toolbar
  • Next by Date: detachDrawingThread problem
  • Previous by thread: Re: Tracking files the right way
  • Next by thread: Re: Tracking files the right way
  • Index(es):
    • Date
    • Thread