[Openmcl-devel] delete-file and directories

[George Khouri]

>
>
>On Mon, 14 Mar 2005, George Khouri wrote:
>
>>  COPY-FILE: On OSX, should COPY-FILE call "CpMac" or something
>> similar, instead of "cp?"  I'm guessing most of us using OSX still
>> have files with resource forks, and will likely have them for a
>> while. How do we detect and copy resource forks in OpenMCL, without
>> making an objc call?
>
>It's a little strange, but the Darwin layer allows the resource fork
>of a file named FOO to be referenced via the name FOO/rsrc.
>
>If you wanted to copy FOO to BAR (and preserve the resource fork), you
>can do it in two steps:
>
>;;; It seems to be necessary to create the output file before
>;;; trying to write to its resource fork
>(copy-file "FOO" "BAR")
>(copy-file "FOO/rsrc" "BAR/rsrc" :if-exists :overwrite)
>
What's ugly is that a program would have to check for the existence of a resource fork and make two calls to copy-file (though some code at some level has to check for and handle two forks anyway). That's not the end of the world for the occasional copy operation, but for copying a large number of files (e.g., one file system to another), it's not very pretty or necessarily efficient.  It seems to me that COPY-FILE should shield the programmer from that detail anyway, especially for some semblance of portability. COPY-FILE in it's current state is unreliable, since it will silently fail to copy a dual-fork file on MacOS, rendering the target file unusable in most cases. One could write a COPY-ANY-MACOS-FILE function, but I think what's important is that COPY-FILE's functionality is conditional on MacOS, in that it doesn't always do what it's advertised to do ...
>
>I would expect pathname-handling functions to be very confused by
>something like #p"/path/too/foo/rsrc", and I think that that confusion's
>justified ...
>
Likewise.