[llvm-commits] [llvm] r118367 - in /llvm/trunk: include/llvm/System/Path.h lib/System/Unix/Path.inc lib/System/Win32/Path.inc

[Michael Spencer]

On Sun, Nov 7, 2010 at 9:04 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Michael Spencer <bigcheesegs at gmail.com>
> writes:
>
>>>> Doesn't windows support a kind of symbolic link nowadays?
>>>
>>> Not sure. Michael? :-)
>>
>> Yes it does. I think it was added to NTFS in Vista. I'm not sure how
>> to check for one, but I'll look into it.
>
> Something like this should do (untested):
>
> WIN32_FILE_ATTRIBUTE_DATA fileData;
> GetFileAttributesEx("some_file", GetFileExInfoStandard, &fileData);
> if( fileData.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT ) {
> ....
> }
>

Attached is a patch that implements it. I would like to discus one
part before committing though:

bool
Path::isSymLink() const {
  DWORD attributes = GetFileAttributes(path.c_str());

  if (attributes == INVALID_FILE_ATTRIBUTES)
    // There's no sane way to report this :(.
    report_fatal_error("GetFileAttributes returned INVALID_FILE_ATTRIBUTES");

  // This isn't exactly what defines a NTFS symlink, but it is only true for
  // paths that act like a symlink.
  return attributes & FILE_ATTRIBUTE_REPARSE_POINT;
}

Most of the other code in System (for both Windows and Unix) ignores
errors. This has been a big issue in bugpoint, which currently treats
quite a few errors (not bugs) in System as errors in the code
generator because it's currently impossible to get errors from System.

I know we plan to rewrite System::Path, but that doesn't seem to be
happening any time soon. So I would like to start explicitly failing
instead of silently failing way down the line.

My ideal world would be to use a C++03 implementation of
std::error_code (which is currently already part of KillTheDoctor),
but that's a much larger change.

I understand the argument that errors such as "file not found" are the
same as saying the path is not a symlink, however, there are other
errors such as permissions, out of memory, other crazyness, etc...
that are not the same. They do not tell you one way or the other if
the path is a symlink (or whatever attribute is in question).

- Michael Spencer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: implement-isSymLink.patch
Type: application/octet-stream
Size: 1120 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101108/e803cffc/attachment.obj>