Re: [Monotone-devel] heads up: file system changes

[Zack Weinberg]

On Wed, Sep 23, 2009 at 11:30 PM, Stephen Leake
<address@hidden> wrote:
> Daniel Atallah <address@hidden> writes:
>> On Wed, Sep 23, 2009 at 07:30, Stephen Leake
>> <address@hidden> wrote:
>>> Zack Weinberg <address@hidden> writes:
>>>
>>> Why is do_remove in platform.hh? The unix implementation requires C90
>>> 'remove'. Are we assuming C90 is not available on Windows? I assume
>>> MinGW provides that (but maybe it doesn't?); do we really care about
>>> any other compiler/runtime?
>>
>> remove() in the Windows CRT only will delete files, not directories:
>> http://msdn.microsoft.com/en-us/library/2da4hk1d%28VS.80%29.aspx
>
> That's the same as Gnu libc:
>
>    Use `remove' to dissolve the association between a particular
>    filename (the string at FILENAME) and the file it represents.
>    After calling `remove' with a particular filename, you will no
>    longer be able to open the file by that name.

That's not the documentation I have for GNU libc ...
http://www.gnu.org/software/libc/manual/html_node/Deleting-Files.html
first describes unlink() [which does not work on directories] and
rmdir() [which only works on directories] and then says

— Function: int remove (const char *filename)

    This is the ISO C function to remove a file. It works like unlink
for files and like rmdir for directories. remove is declared in
stdio.h.

> Right. But in this case, it is an implementation of the standard C
> library.

I checked - contra my recollection, neither C90 nor C99 even has the
concept of directories.  The horse's mouth, therefore, is POSIX, which
says

# The remove() function shall cause the file named by the pathname
pointed to by path
# to be no longer accessible by that name. A subsequent attempt to
open that file using
# that name shall fail, unless it is created anew.

# If path does not name a directory, remove(path) shall be equivalent
to unlink(path).
# If path names a directory, remove(path) shall be equivalent to rmdir(path).

The second paragraph is marked as an extension to C90.

POSIX.2001, incidentally, is available online at
http://www.opengroup.org/onlinepubs/009695399/nfindex.html (free
registration required).  You have to read it carefully because not
every system that we care about implements all of the 2001 spec, but
it's a good starting point.

> However, the actual difference between the code in win32 and unix
> deals with what happens when the file to be removed does not exist.
> The Gnu libc manual quoted above does not specifically address this
> issue, so perhaps it is implementation dependent. Windows returns an
> error in this case; apparently "Unix" (whatever that is :) does not.
>
> I could not find the actual ISO C runtime library definition (I think
> I have a book at work), so I'm not clear what that says.

That might actually be a bug.  The underlying Unix system calls
[rmdir() and unlink()] do return an error code if the last component
of the pathname doesn't exist.  I'm not sure whether our
platform-independent code expects do_remove() to succeed in that case.
 do_remove_recursive definitely does need to succeed then, though.

zw