Re: some NSFileManager bugs

[Richard Frith-Macdonald]

On Saturday, July 6, 2002, at 12:23 PM, Enrico Sersale wrote:

> 1) copy the directory to an other location, for example "GSPdf_copy"
> (I'm not using GWorkspace for this, only a simple program that calls
> NSFileManager's -copyPath:toPath:handler: in main).
>
> well, only the directories will be copied and, moreover, "obj" is not
> anymore a symbolic link but a directory and contains the contents of
> "./shared_debug_obj/ix86/linux-gnu/gnu-gnu-gnu".

I couldn't reproduce this.

> 2) try now to create an empty directory and copy *the contents* of the
> first dir to the second one.
>
> in this case, all the files are copied but "obj" is not anymore a 
> symbolic
> link;

This didn't happen for me either, but I can see how it could be caused
(had I written a different test program) by a problem I did discover
later.

> 3) now, using -removeFileAtPath:handler: try to remove the entire
> directory "GSPdf" (the first one, that with the symbolic link).
>
> the directory will not be removed and, if you cd into it, you will see
> that all the files have been removed but not "obj".
>
> run again your little program and, this time, the directory will be
> deleted.

This one I could reproduce, and I tracked it down to a bug in converting
from internal representation of a path to C-string representation.  This
was potentially very nasty as it could cause files to be removed which
shouldn't be!
I have therefore put a fix into the 1.4.0 freeze branch in CVS.