Doug Turner wrote:
> Removing explict symlink function.
As someone who spent many hours fighting in the symlink-semantics wars,
I really want to hear an excruciating clear description of what happens
when various types of links (to files, to directories, dangling) are
operated on in various ways.
> The biggest change is that nsIFile and nsILocalFile should be split into
> two logical pieces: file description and the file system service. The
> first piece would just be basic filepath manipulation, initalization,
> and stat getters.
stat is a filesystem operation, I think, unless you want to generalize
it to apply to all path-like things (file: URLs? all URLs?). nsIFile
should be about filepath mechanics, and anything that interacts with a
filesystem (or moral equivalent, in the case of remote URLs) should be
in the other service.
And while you're moving that stuff around, I think it's _imperative_
that we fix the current issues with stat caching and the like: stat data
should be reflected in another interface, which will permit the API
consumer to make stat calls efficiently, and provide
as-atomic-as-possible access to the data in question. There's a bug
about this somewhere, but I can't find it at the moment.
> The first additional comment is that we should remove the non unicode
> version of all methods. I believe that i18n will be happy with this.
> However, I am not sure how this will effect most users. Looking over
> the codebase, most places we are dealing with unicode anyways, however,
> there may be places which will have to convert from ansi to unicode.
I second Jon Smirl's concern over the fate of XPCOM_STANDALONE, and am
somewhat saddened to see that we want to make our whole product bear the
memory and computation burden of UCS-2/UTF-16 paths when the _vast_
majority of our paths live happily in 7 bits.
> The second additional change is that the followSymlink attribute will
> apply to the terminal node during appending (which may include
> initialization of the nsIFile), as well as any of the FileSystem
> functions. This allows us to compress/remove all of the
> "followingSymlink" functions. So, supposing you have a nsIFile of a
> directory, and you wanted to copy it somewhere while resovling the
> symlink, you could simply set the followingSymlinks flag to true, then
> call into the FileSystem service. Another example, is if got a nsIFile
> from the directory service and you wanted to append a relative path
> which may contain a symlink, you would again set this flag to true, then
> call |append|. Unlike the current interfaces, if you set the flag back
> to false, your working path will still be valid.
I think I like this change, but want to think more about it.
Mike
