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

[Stephen Leake]

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:

    *Synopsis*
         #include <stdio.h>
         int remove(char *FILENAME);

         int _remove_r(struct _reent *REENT, char *FILENAME);

    *Description*
    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.

> Note that MinGW doesn't really provide API - it is just a compiler and
> set of headers / link libraries, so it is dependent on the native
> win32 behavior.

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

> Interestingly in platform.hh there is a comment stating that the
> "path" argument to do_remove()  "must be a file, not a directory", but
> that appears to not be correct - is that correct or not?

Sounds like it is.

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.

>>> Notionally, in the future, we might want to switch everything in
>>> win32/fs.cc over to the Unicode APIs, and do_remove_recursive would be
>>> no exception, but I surely am not doing that work.
>>
>> Ok; I added a comment about this.
>
> From a Windows perspective, conversion to use Unicode APIs is pretty
> much the only way to go to ensure all (legal) filenames are supported.
>
>> But it would seem a better approach is to enhance any_path objects to
>> support all OS-supported filenames. Does that mean it has to be UTF-8?
>> I guess that might also require fs.cc to use the Unicode APIs.
>>
>> Does C90 not deal with this in a portable way?
>
> To the best of my knowledge, the concept of filename encoding isn't
> really addressed at all in C90.
>
> The approach that things like Glib use is to ensure consistency within
> the API (all paths are UTF-8); then wherever direct interaction with
> the filesystem occurs, the path is converted to the relevant encoding
> (in the Windows case, this is conversion to a UTF-16 wchar*).  I think
> this is the right way to do it.

Ok, thanks.

-- 
-- Stephe