Oh yeah, one trivial improvement to MappedFile would remove a syscall:

void MappedFile::initialize() {
if (path_.exists()) {
info_ = new MappedFileInfo;
...
info_->fd_ = ::open(path_.c_str(),mode);

if (info_->fd_ < 0) {
  delete info_;
  info_ = 0;
  ThrowErrno(std::string("Can't open file: ") + path_.toString());
}

There is no reason to call Path::exists (a syscall). Instead, just call open, and if it fails, you know the file
doesn't exist. Also, the error path code would be simpler and faster if MappedFileInfo were allocated
later.

-Chris

1. is easy, will do.
2. is already supported with the appendComponent method
3. can't be made to work portably without a lot of fudging. Windows has no
   concept of links and so no "unique identity" for files. About the only thing
   that could be done is generate an md5sum on the file name and hope that it
   doesn't collide
4. Use eraseComponent.
5. Use getDirectoryContents

The FileStauts info will be cached in my next commit.

These patches:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046411.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046412.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046413.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046417.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046419.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046420.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046421.html

implement #​1, #​3, and the caching of file status.

With these patches:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046438.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046446.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046448.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046449.html

all requested functionality for this PR has been implemented.

Thanks Reid!!

Question, isn't \network\device\blah absolute on win32?

-Chris

Yes, it is. And, Jeff C already fixed it :)

Since I can't (easily) compile for win32, I just write place holders and Jeff
cleans it up.

There's one remaining issue for this: uniqueness of Paths via the UniqueID field
of the FileStatus structure. It will work fine on Unix (Inode #) but currently
won't work well on Win32 unless the path strings are identical. Jeff has a way
to get a unique id for each file from Win32, but the file has to be open first!
(go figure).

So, this is currently an unresolved issue on win32 port. Perhaps I should open
a bug for that.

Jeff C already fixed it :)

Ah, woot!

So, this is currently an unresolved issue on win32 port. Perhaps I should open
a bug for that.

Okay, either way. Since we don't have a client for this yet, it isn't a big deal.

It will work fine on Unix (Inode #)

This needs to be an inode/volume number pair,

-Chris