Author brian.curtin
Recipients brian.curtin, eric.smith, georg.brandl, jason.coombs, loewis, nadeem.vawda, ocean-city, santoso.wijaya
Date 2011-05-28.01:07:50
SpamBayes Score 2.42621e-07
Marked as misclassified No
Message-id <1306544871.61.0.196186986172.issue12084@psf.upfronthosting.co.za>
In-reply-to
Content
It turns out DeviceIoControl/FSCTL_GET_REPARSE_POINT (in win32_read_link) will only work for us as long as the symlink was created with a full path. Starting at the top level of a source checkout, if I create `os.symlink("README", "README.lnk")` and then do `os.stat("..\\README.lnk")` from up a directory (or any other directory), DeviceIoControl can only find out that the symlink was created with "README", so the reparse tag it knows about is "README", which doesn't really help us in figuring out where that file is actually located. Everything is fine if I create the symlink with full paths.

I'm in the middle of refactoring this to work with GetFinalPathNameByHandle. I had thought about a quick-and-dirty solution of modifying os.symlink to convert all paths into fully qualified paths in order to give DeviceIoControl the info it needs for os.stat...but that doesn't help for any previously created links, or for any links created by Microsoft tools such as the "mklink" command line tool (it doesn't set the reparse tag with a fully qualified path either).
History
Date User Action Args
2011-05-28 01:07:51brian.curtinsetrecipients: + brian.curtin, loewis, georg.brandl, jason.coombs, ocean-city, eric.smith, nadeem.vawda, santoso.wijaya
2011-05-28 01:07:51brian.curtinsetmessageid: <1306544871.61.0.196186986172.issue12084@psf.upfronthosting.co.za>
2011-05-28 01:07:51brian.curtinlinkissue12084 messages
2011-05-28 01:07:50brian.curtincreate