New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
os.lstat/os.stat don't set st_nlink on Windows #54236
Comments
In msg117834 on bpo-8879 it was noticed that os.lstat and os.stat don't set st_nlink on Windows, which is causing the patch on that issue to fail test_tarfile. Attached is a stripped down version of the patch Hirokazu Yamamoto proposed on bpo-8879, containing just the os.*stat changes. As stated in that message, the patch is a quick hack to get test_os and test_tarfile working, so it could use review. |
Overall I think this looks like a reasonable restructuring, and it works in a few manual tests of existing hardlinks on my system. Until bpo-8879 goes in, we can't really add tests for this. Hirokazu, do you want to commit this since you came up with it? |
There are some questions.
/* Get WIN32_FIND_DATA structure for the path to determine if
it is a symlink */
if(info.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
find_data_handle = FindFirstFileA(path, &find_data);
if(find_data_handle != INVALID_HANDLE_VALUE) {
if(find_data.dwReserved0 == IO_REPARSE_TAG_SYMLINK) {
/* first clear the S_IFMT bits */
result->st_mode ^= (result->st_mode & 0170000);
/* now set the bits that make this a symlink */
result->st_mode |= 0120000;
}
FindClose(find_data_handle);
}
}
/* Set S_IFEXEC if it is an .exe, .bat, ... */
dot = strrchr(path, '.');
if (dot) {
if (stricmp(dot, ".bat") == 0 || stricmp(dot, ".cmd") == 0 ||
stricmp(dot, ".exe") == 0 || stricmp(dot, ".com") == 0)
result->st_mode |= 0111;
}
Thank you. |
P.S. Thank you for acceptance. I really wanted to commit |
Jason, any idea on #2? |
I'm unsure. I think when I addressed the issue, I was only concerned with symlinks. The Vista behavior sounds correct to me, so it may be that XP was left with the legacy behavior as it doesn't have native symlink support. It sounds as if the behavior on XP should be modified to follow the same technique as in Vista. I don't know when I'll have a moment to look at it in depth, but I'll try to in the next week or two. |
How about this patch?
I hope other behavior was not changed by this patch. |
... I noticed I can test this via buildbot... |
I'll also give it a run on my Windows machines but won't be able to until tomorrow morning (~1300 UTC). |
I noticed stat() won't set S_IEXEC in stat() |
I replaced my patch (almost reverted stat() part) |
I created test branch "branches/py3k-stat-on-windows" and |
Works for me. I think it should be ok to commit. |
I found Win32 FileID API. With this library, it seems I don't have a patch, but maybe it is worth to implement it. |
I'm not sure how that would work in terms of redistributing, and how we'd handle it within our own build process. This close to the beta I'm -1 on adding that API. |
Thank you for reply. Could you commit my last patch |
Committed to py3k in r86727. I think this should be backported to the maintenance branches, but not until after the upcoming point releases. Although those branches won't have the ability to create hard links, they should have the ability to view information about existing links on the system (or if they create them via ctypes/pywin32). Since those branches won't be able to explicitly test this, I think it makes sense to let this bake for a while on py3k. |
Thank you for commit! |
This code has changed a lot since originally being committed, so I'll handle backporting in bpo-12084 which has the latest changes. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: