[CMake] File remove_recurse doesn't on OSX

[David Cole]

On Wed, Mar 16, 2011 at 2:02 PM, Belcourt, Kenneth <kbelco at sandia.gov> wrote:
>
> On Mar 16, 2011, at 11:57 AM, Belcourt, Kenneth wrote:
>
> On Mar 16, 2011, at 11:46 AM, David Cole wrote:
>
> On Wed, Mar 16, 2011 at 1:40 PM, Belcourt, Kenneth <kbelco at sandia.gov>
> wrote:
>
> Hi,
>
> A quick bug report with CMake 2.8.4 on OSX 10.5.8 built with Intel 11.0.064.
>
>  This command works fine
>
> file(REMOVE ${Bwr_Files})
>
> while this one fails.
>
> file(REMOVE_RECURSE ${Bwr_Files})
>
> And by fails I mean it doesn't remove any files at all, much less
>
> recursively.  This should be easy to reproduce, do I need to file a bug or
>
> can this get fixed for 2.8.5?
>
> The arguments to file(REMOVE_RECURSE are intended to be directory
> names. Are they?
>
> One of the names is a directory, the rest are files.
> set(Bwr_Files
>   ${Bwr_Dir}/acoeff.txt
>   ${Bwr_Dir}/BWRG_v2-0.DIA
>   ${Bwr_Dir}/BWRG_v2-0.OUT
>   ${Bwr_Dir}/BWR_OUT.HTM
>   ${Bwr_Dir}/BWR_v2-0.DIA
>   ${Bwr_Dir}/BWR_v2-0.MES
>   ${Bwr_Dir}/BWR_v2-0.OUT
>   ${Bwr_Dir}/BWR_v2-0.PTF
>   ${Bwr_Dir}/BWR_v2-0.RST
>   ${Bwr_Dir}/extDIAG_v2-0
>   ${Bwr_Dir}/fort.32
>   ${Bwr_Dir}/fort.36
>   ${Bwr_Dir}/HTML
>   ${Bwr_Dir}/MELGIN_v2-0.CAN
>   ${Bwr_Dir}/NodeDiagram.html
>   ${Bwr_Dir}/tmpry
> )
> The funny thing is remove_recurse works as expected on Linux, it removes the
> files and recursively removes the directories.  On the Mac remove_recurse
> does nothing at all but file(remove ...) on the Mac works as expected, it
> just leaves the directories alone.
>
> Is the Mac file system in question case-sensitive, or
> case-insensitive? (By default, most Macs are case-insensitive... and
>
> and case-preserving.  Yes, this particular disk is the default.
>
> but it would help if it was the Leopard disk.
>   Volumes:
> LeopardOSX:
>   Capacity: 232.76 GB
>   Available: 34.45 GB
>   Writable: Yes
>   File System: Journaled HFS+
>   BSD Name: disk2s2
>   Mount Point: /
>
> we've had other reports of file weirdnesses on
> case-sensitive-file-system-based Macs -- we do not have one of these
> presently here at Kitware, so it's hard for us to repro any such bugs
> to figure out if there is a good fix or not. Suggestions welcome.)
>
> What command is run on the Mac, any easy way to find out?  The file(remove
> ...) works okay, I'd have guessed that file(remove_recurse ...) just adds
> the -r option to the rm -f command.
> -- Noel
> <ATT00002..txt>
>

Well, sugar. (In the expletive sense...)

Looks like cmFileCommand.cxx has an implementation of
cmFileCommand::HandleRemove that implements both REMOVE and
REMOVE_RECURSE and it ........ (wait for it) .......... always returns
true. Always. Regardless of any failed attempts at removing files. We
completely ignore the return value of the underlying file system
remove calls.

It's probably failing for some permissions, ownership or locking
related reason, but file(REMOVE provides no error diagnostics. Do you
have permissions to remove the directory in question? Is there an
executable down in that directory that is open/running when this
attempt is made? (An open app on the Mac cannot be deleted until it is
not running anymore...)

Grrr. Good (but bad) bug find. Do you have time to add a bug at
http://public.kitware.com/Bug ?

Is this reproducible in general on your Mac, or is it specific to the
one directory?

If a general problem, then the following code should leave the
directory and produce a FATAL_ERROR:
  file(MAKE_DIRECTORY test_dir)

  file(WRITE "test_dir/file1" "file1 contents")
  if(NOT EXISTS "test_dir/file1")
    message(FATAL_ERROR "test_dir/file1 does not exist!! should be
created by now")
  endif()
  if(NOT EXISTS "test_dir")
    message(FATAL_ERROR "test_dir does not exist!! should be created by now")
  endif()

  file(REMOVE_RECURSE "test_dir")
  if(EXISTS "test_dir/file1")
    message(FATAL_ERROR "test_dir/file1 still exists!! should be deleted now")
  endif()
  if(EXISTS "test_dir")
    message(FATAL_ERROR "test_dir still exists!! should be deleted now")
  endif()

And finally: does it still happen after a reboot?

Hopefully people won't complain about "backwards compatibility" issues
that arise when we fix it.


Thx,
David