Mike Shaver wrote:
> 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.
I too have had to wrap my brain around all the issues with xp symlinking. The
root problem that we tried to make windows and the mac do auto resolving.
This sucks cause on these platforms, it is expensive and ugly to try to
resolve links. Without digging to deep, I want to see the mac and window
nsLocalFile impl knowing NOTHING about symlinks implictly. There will be a
call on the nsIFile (or in that file system service) that will resolve only
the terminal node and either return a new nsIFile or modify the current
nsIFile.
This is much simpiler than what we have now.
> > 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.
>
right. I think that is what I said. Two parts: A state part and a function
part.
> 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.
what problems? Please dig up some bugs.
> > 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.
CCing ftang.
Frank, you added unicode paths to the nsIFile. A couple of questions:
Why do we need unicode paths on the nsIFile?
Can't consumer convert before calling into this interface? Can we have macros
outside of this interface?
What about callers from JS via xpconnect, what charset are those paths used
when being converted to char*'s?
