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

[Daniel Atallah]

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

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.

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?

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

-D