[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Possible bug in NSFileManager
From: |
Richard Frith-Macdonald |
Subject: |
Re: Possible bug in NSFileManager |
Date: |
Sat, 9 Mar 2002 11:24:38 +0000 |
On Saturday, March 9, 2002, at 07:48 AM, e.sammer wrote:
Richard Frith-Macdonald wrote:
On Saturday, March 9, 2002, at 12:20 AM, e.sammer wrote:
I assume you mean in [copyPath:toPath:handler:] (there is no copyFile:
method) ... it should work there.
As far as I can see from quick look over the code, it should honor the
documentation to the letter -
but the documentation is not completely unambiguous :-(
in reading the mosx api reference, states the following:
"Copies the directory or file specified in path source to a different
location in the file system identified by path destination. If source
is a file, the method creates a file at destination that holds the
exact contents of the original file (this includes BSD special files).
If source is a directory, the method creates a new directory at
destination and recursively populates it with duplicates of the files
and directories contained in source, preserving all links. The file
specified in source must exist, while destination must not exist prior
to the operation. When a file is being copied, the destination path
must end in a file name-there is no implicit adoption of the source
file name. Symbolic links are not traversed but are themselves copied."
(the above is taken from the first paragraph of
copyPath:toPath:handler: in NSFileManager at apple's dev site)
the way i read it was that sym links were copied to the destination
path and underwent no additional traversal (as per the last line). of
course, i could be wrong.
But it's not clear whether that's talking about links within a
directory, or includes the actual source argument.
It also does not define what copying a symbolic link actually means
here - whether a copy of a link should point to
the original file, or to a copy of the original file.
i can't seem to find a copy of the OpenStep spec anywhere online
(thanks Sun / Apple) so i couldn't check it for reference. i thought
there was a link somewhere on the GS site, but i can't find that either.
Could you provide a small test program to demonstrate your problem.
at the bottom is a quick tool that shows the error. use it to try and
copy a link to a file or a link to a directory.
I'm guessing that you (and MacOS-X?) are using the interpretation that
if the source argument is a symbolic
link, we should copy the link rather then the file or directory it
points to. I can't see what else the
program could demonstrate. It doesn't tell me what should happen when
copying symbolic links inside a
directory hierarchy though.
While the code seems to conform to the letter of the documentation,
I'm not at all sure it does the
most intuitive/useful thing. It seems to be preserving the original
symbolic links - but I'd have
thought it made more sense, if a link pointed to somewhere within the
path being copied, for the
new symbolic link to be made to the appropriate location within the
copied structure.
i might be missing what you're saying here... if you're saying it would
make more sense for me to copy the real file and then just make a new
link, it's possible, but certainly not convienient. the method of
retrieving the file pointed to by a link seems unreliable (if i recall)
if at all possible. i'm sure it's one of many solutions... just not too
comfortable with that one.
No, that's not what I meant at all ... I think I misunderstood your
original query.
This is what I was talking about - consider a directory D containing a
file F and a symbolic link L which points to F
If you copy D you produce a directory D' containing a file F' and a link
L'
The question is - should L' point to F or F' ?
The current implementation would set L' to point to F, but I think it
would make more sense the other way.
I'd be very happy to apply patches to fix this to provide the same
real (as opposed to documented) behavior
i'm not sure what you mean by real vs. documented behavior. i was under
the impression that the real behavior was the documented behavior.
Sometimes the two are not the same.
Often the documentation is ambiguous and could be read two or more ways.
Very often, the documentation is incomplete and some cases are simply
not described.
- as long as the real MacOS-X behavior is not clearly
a bug of course.
again, as i read the docs, it seemed clear as to what the intended
behavior is or was supposed to be.
Well, I didn't write the code we are talking about - but it seems plain
to me that it *does* conform
to one possible reading of the documentation. Not the most obvious
interpretation to me (or you),
but presumably the most obvious one to the original author.
What I want to ensure is that when it's changed, the change matches the
MacOS-X implementation.