Re: Changing file & directory names
Re: Changing file & directory names
- Subject: Re: Changing file & directory names
- From: Sherm Pendley <email@hidden>
- Date: Sat, 1 Jul 2006 17:10:56 -0400
On Jul 1, 2006, at 3:57 PM, Dean Snyder wrote:
Sherm Pendley wrote at 3:41 PM on Saturday, July 1, 2006:
I'm not debating what words are used, I'm pointing out that you've
misunderstood them.
Huh?
I insist you are misunderstanding the words, but I am also saying
at the
same time that you may have the right understanding of what is
actually
going on, in spite of what the documentation says. I just don't know -
all I have to go by is the documentation.
What? You also have commentary from random strangers on the internet
to go by! Isn't that enough? :-)
So you're saying that there is no new file creation going on with
NSFileManager movePath?
Sorry for the Clinton-esque answer, but that depends on precisely
what you mean by "file creation". A new directory entry is created
points to the original file's contents. (man 2 link). Then, the
original directory entry is removed. (man 2 unlink). At no time is
the contents of the file duplicated, just the directory entries.
Also, keep in mind the limitations of link() - one cannot create a
link that crosses volumes. So moving a file from one drive to another
*will* copy the data. Shuffling directory entries is basically just
an optimization for the very common case of the source and
destination being on the same volume.
Another thing link() can't do is create a link to a directory. That's
what the docs are referring to when they talk about recursive
behavior. Moving a directory actually does mean creating a new one;
after it's been created, files are moved into it with link()/unlink
(). Rinse and repeat for subdirectories.
Then why do both the created and modified dates
of the just "moved" file equal the time of "moving" and not, for
example, the "real" created time?
That's essentially a policy decision. There's no technical reason why
that would have to be the case, but obviously someone thought it
would be a good idea.
I'm not complaining to you about the documentation - I'm complaining
about the fact that you said I misunderstood it. I don't believe I
have.
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.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
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