Re: Possible bug in NSFileManager

[Richard Frith-Macdonald]

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.