Fwd: Re: [Openmcl-devel] delete-file and directories

[George Khouri]

Thanks for the replies, Gary and all.
I also agree that we should have a DELETE-DIRECTORY, and I think your point about the fact that we have only a few filesystems in widespread use is worth considering.

Practically speaking, it has been very convenient for me as programmer who works extensively with filesystems to have one function, DELETE-FILE (in MCL) to delete a pathname passed to it, whether file or directory. Perhaps we should have a pathspec-encompassing function, DELETE-PATH, which would do the work. Maybe someday we won't have filesystems (on disk drives, anyway) as we know them, though we'll probably have a (node-based?) PATH to some information, and DELETE-FILE was a bad name choice to begin with.  

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?

George Khouri

>On Sat, 12 Mar 2005, Gary Byers wrote:
> ...
>
>I also agree that the spec leaves a lot intentionally unsaid; it
>says that DELETE-FILE deletes the -file- specified by its filespec
>arg; the glossary entry for "file" says only that it's a named
>entity that lives in the filesystem and whose nature is implementation-
>dependent.  (So, it's not necessarily incorrect for an implementation
>to interpret "file" to include "directories", and may be very reasonable
>to do so in at least some hypothetical file systems.)
> ...
>
>(defun DELETE-DIRECTORY (pathname &optional (recursively nil))
>  ...)
>
>e.g., it seems that it'd be desirable to maintain this distinction.
>(There might be other plausible options: if some of the directory's
>contents can't be deleted because of permission issues, how should
>the function behave?  Etc.)
> ...
>I could sort of believe that existing lisps -could- standardize on
>some sort of de facto standard DELETE-DIRECTORY function, at least
>partly because there are really only 2 or maybe 3 filesytems in
>widespread use today and they all offer similar semantics.
>