• 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: Changing file & directory names
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changing file & directory names


  • Subject: Re: Changing file & directory names
  • From: Derrick Bass <email@hidden>
  • Date: Sat, 1 Jul 2006 19:28:11 -0500

On Jul 1, 2006, at 4:10 PM, Sherm Pendley wrote:

Belief is unnecessary - just test it. Dump a huge file on your disk somewhere, then use -movePath:toPath:handler: to move it. For a large enough file (a CD or DVD image, for instance), it would be immediately apparent which is the case - if the file's contents were being copied, there would be a noticeable delay.

I was so astonished by this thread that I did, indeed test it. I don't think I ever even bothered to read the documentation on movePath:toPath:handler: because it never occurred to me that it would not work just the UNIX mv command: if the source and destination are on the same volume, then the file/directory is simply moved, otherwise it is copied. By moved I mean the directory entry is removed from the source directory and placed into the destination directory (which, by the way, has nothing to do with link (2) and unlink (2) but rather with rename (2)).


This is, in fact, what happens.

Also, I'm but confused by Sherm Pendley's mention of link and unlink. I think he's assuming it is correct but needs a tortured interpretation in order to reconcile it with our notion of what should happen. Anyway, he's right that no copies are made. But also, no hard links are made, either. As someone else pointed out, it is actually possible on HFS+ to detect whether or not a file has ever had multiple links. Once it is multiply linked, it acts forever differently, even if all but one of those links is subsequently deleted. The easiest way to see the difference is with hfsdebug.
<http://www.osxbook.com/software/hfsdebug/>


(I suppose one could also do a test like Sherm's by making a directory with a huge number of files; if hard links were being made to all those files, it would take a noticeable amount of time; I did not try this.)

The documentation is simply incorrect. I suspect that all that stuff about copying the file and then deleting the original, or doing a recursive copy for a directory was supposed to be preceded by words like "If the the source and destination are not on the same volume" and those words somehow never made it in.

Anyway, for the OP, go ahead and use movePath:toPath:handler:. And file a bug report on the documentation.

Derrick

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Changing file & directory names
      • From: Sherm Pendley <email@hidden>
References: 
 >Changing file & directory names (From: Dean Snyder <email@hidden>)
 >Re: Changing file & directory names (From: Greg Titus <email@hidden>)
 >Re: Changing file & directory names (From: Dean Snyder <email@hidden>)
 >Re: Changing file & directory names (From: Sherm Pendley <email@hidden>)
 >Re: Changing file & directory names (From: Dean Snyder <email@hidden>)
 >Re: Changing file & directory names (From: Sherm Pendley <email@hidden>)
 >Re: Changing file & directory names (From: Dean Snyder <email@hidden>)
 >Re: Changing file & directory names (From: Sherm Pendley <email@hidden>)

  • Prev by Date: Re: Changing file & directory names
  • Next by Date: Re: Changing file & directory names
  • Previous by thread: Re: Changing file & directory names
  • Next by thread: Re: Changing file & directory names
  • Index(es):
    • Date
    • Thread