5

I used _stat64(const char *path, struct __stat64 *buffer); API to get the file/directory stats but this API fails if input path contains a symbolic link.

GetFileAttributes() and GetFileAttributesEx() APIs too fail if file path contains a symbolic link. But as mentioned at MSDN, If the path points to a symbolic link, these two functions returns attributes for the symbolic link. Even _stat64() works if path points to symbolic link.

Is there any way to get the states/attribues of file/directory if path contains [not points to] a symbolic link ?

For instance - how to get attributes of "test" directory if input path is "D:\temp\symbolic_link\test"

[Edit1] Since eryksun's comment made sense. I tried GetFileAttributesEx() and _stat64() again. It worked but this time I had granted the full permissions to target directory and symbolic link both. It appeared to be permission issue. If I pass "D:\temp\symbolic_link" then I get attributes/stats of symbolic link and if I pass "D:\temp\symbolic_link\test" then I get attributes/stats of test directory which is expected.

irsis
  • 952
  • 1
  • 13
  • 33
  • Which Windows version? `GetFileAttributes` traverses directory symbolic links for me in Windows 7. – Eryk Sun Oct 14 '14 at 08:58
  • @eryksun I am also on windows 7. Did you pass D:\temp\symbolic_link\test or D:\temp\symbolic_link to GetFileAttributes() ? It fails for first path but works for second path. – irsis Oct 14 '14 at 10:45
  • I created a directory symbolic `mklink /d C:\Source\test\symbolic_link C:\Windows`, and then called `GetFileAttributesW(L"C:/Source/test/symbolic_link/System32")`. – Eryk Sun Oct 14 '14 at 12:11
  • @eryksun Did that work ? It doesn't at least in my system. – irsis Oct 14 '14 at 13:11
  • That's what I had tested (in both 32-bit and 64-bit) before making my initial comment. That it fails for you is puzzling since the kernel is making pretty much the same I/O and object manager calls that would parse the path and open the directory in other contexts. For example, I wouldn't expect you'd be able to create a file in the target directory. – Eryk Sun Oct 14 '14 at 13:34
  • Is the symbolic link actually working, e.g., can you say `dir d:\temp\symbolic_link\test` ? Perhaps symbolic links are disabled on your computer, see what `fsutil behavior query SymlinkEvaluation` says. – Harry Johnston Oct 15 '14 at 00:17
  • Why -1 ?IMO, it's valid question. I even have got an answer. Yes, Symbolic link is very much working and dir command clearly says that D:\temp\symbolic_link is of type – irsis Oct 15 '14 at 04:49

1 Answers1

5

None of the MSDN pages say anything related to your issue, but you may want to obtain the real path of your file by doing something like this:

void realpath(const char *filename, wchar_t *pathbuf, int size)
{
    OFSTRUCT of;
    HANDLE file = (HANDLE)OpenFile(filename,&of,OF_READ);
    GetFinalPathNameByHandle(file,pathbuf,size,FILE_NAME_OPENED);
    CloseHandle(file);
}

This will fill pathbuf with the reparsed path name of your file (up to the length of size).

I hope this helps.

Géza Török
  • 1,397
  • 7
  • 15
  • Thanks Geza. Even I thought the same once I found this anser http://stackoverflow.com/questions/221417/how-do-i-programmatically-access-the-target-path-of-a-windows-symbolic-link. I'll wait for few days before marking it answer hoping someone has better suggestion. – irsis Oct 14 '14 at 08:50
  • The issue I faced might be due to permissions but my problem will be solved by using GetFinalPathNameByHandle(file,pathbuf,size,FILE_NAME_OPENED); API. – irsis Oct 15 '14 at 06:33