Stream: git-wasmtime

Topic: wasmtime / PR #1199 Implement path_link for Windows.

Wasmtime GitHub notifications bot (Mar 04 2020 at 14:13):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 04 2020 at 14:22):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 04 2020 at 16:03):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 04 2020 at 17:12):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 04 2020 at 19:52):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Mar 04 2020 at 19:52):

peterhuene created PR Review Comment:

Should this be test_path_link_nonstrict for convention's sake?

Wasmtime GitHub notifications bot (Mar 04 2020 at 20:32):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 04 2020 at 20:34):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 04 2020 at 21:17):

kubkon submitted PR Review.

Wasmtime GitHub notifications bot (Mar 04 2020 at 21:17):

kubkon created PR Review Comment:

This looks like a good choice of errno value here, but I'd like @sunfishcode to double check that though.

Wasmtime GitHub notifications bot (Mar 04 2020 at 21:17):

kubkon submitted PR Review.

Wasmtime GitHub notifications bot (Mar 04 2020 at 21:17):

kubkon created PR Review Comment:

Hmm, I think I'd prefer if we had two versions of the testcase, not necessarily overlapping in any way, but such that the "strict" tests are executed only on supported *nix platform, while the rest always executes the "nonstrict" set.

Wasmtime GitHub notifications bot (Mar 06 2020 at 09:52):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 06 2020 at 10:14):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 06 2020 at 10:16):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 06 2020 at 10:23):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 06 2020 at 10:28):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 09 2020 at 15:49):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

Wasmtime GitHub notifications bot (Mar 11 2020 at 11:55):

marmistrz edited PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 12 2020 at 17:46):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:28):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 09:46):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 10:27):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 10:34):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 10:38):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 10:58):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 20:53):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 13 2020 at 20:57):

marmistrz created PR Review Comment:

Done, the non-strict version is no more!

Wasmtime GitHub notifications bot (Mar 13 2020 at 20:57):

marmistrz submitted PR Review.

Wasmtime GitHub notifications bot (Mar 18 2020 at 18:47):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 18 2020 at 20:05):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 18 2020 at 20:28):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 08:00):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 08:01):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 08:19):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 08:35):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 09:19):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 09:20):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 09:34):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 09:55):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 10:32):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 19 2020 at 10:49):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 13:34):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 13:38):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 13:42):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 14:10):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 14:19):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 14:21):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 14:23):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 14:25):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 17:55):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 19:18):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 20:38):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 22:37):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 23 2020 at 22:57):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 07:06):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 08:59):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 09:19):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 09:36):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 09:45):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 09:45):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 10:04):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 10:13):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 10:21):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 11:45):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 24 2020 at 12:44):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:08):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:11):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:14):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:23):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:28):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:29):

marmistrz requested peterhuene and sunfishcode for a review on PR #1199.

Wasmtime GitHub notifications bot (Mar 25 2020 at 15:30):

marmistrz requested peterhuene, kubkon and sunfishcode for a review on PR #1199.

Wasmtime GitHub notifications bot (Apr 01 2020 at 23:58):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Apr 02 2020 at 00:31):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 00:31):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 00:31):

peterhuene created PR Review Comment:

If we remove the RAII type, we should remove or update this comment. Calling out that the fd_close must be called prior to unlinking on Windows probably isn't worth a comment, but I'm also good with updating this comment to reflect that.

Wasmtime GitHub notifications bot (Apr 02 2020 at 00:31):

peterhuene created PR Review Comment:

Is this TODO comment actionable or can it be removed?

Wasmtime GitHub notifications bot (Apr 02 2020 at 00:31):

peterhuene created PR Review Comment:

Rather than using an RAII type for this single test, perhaps we should just insert the fd_close calls in the three places that are needed?

Wasmtime GitHub notifications bot (Apr 02 2020 at 00:31):

peterhuene created PR Review Comment:

We can remove this comment now I think.

Wasmtime GitHub notifications bot (Apr 02 2020 at 13:51):

marmistrz submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 13:51):

marmistrz created PR Review Comment:

What's wrong with RAII here?

Wasmtime GitHub notifications bot (Apr 02 2020 at 13:59):

kubkon submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 13:59):

kubkon created PR Review Comment:

I'm also eager to remove RAII here. It makes the test logic somewhat clunky since we have to force nested scoping for the drop to fire. I cannot see why manually calling fd_close on all needed resources should be inferior to using the RAII type.

Wasmtime GitHub notifications bot (Apr 02 2020 at 16:55):

marmistrz submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 16:55):

marmistrz created PR Review Comment:

I'm removing this mapping, because there is no clear reason why it's needed, just as in #1359.

Wasmtime GitHub notifications bot (Apr 02 2020 at 16:56):

marmistrz submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 16:56):

marmistrz created PR Review Comment:

Okay, I'll remove RAII.

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:01):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:01):

marmistrz submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:01):

marmistrz created PR Review Comment:

Done

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:01):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:01):

peterhuene created PR Review Comment:

Yeah, I wouldn't say there's anything wrong with it by itself, just that it's a little bit of implementation that only saves three fd_close calls in a single test case.

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:02):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:08):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Apr 02 2020 at 17:16):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Apr 02 2020 at 18:01):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Apr 02 2020 at 18:02):

marmistrz updated PR #1199 from path_link to master:

This is probably the last missing syscall for Windows!

This PR implements path_link for Windows and adds a non-strict version of the path_link integration test.

I'm unsure about the error handling in path_link. MSDN doesn't say much about possible error codes for either CreateHardLinkA or CreateSymbolicLinkA. I mostly copied over the error conversion from path_symlink, but I'm not sure if it's correct. In particular, it's unclear to me what the purpose of strip_trailing_slashes_and_concatenate is.

path_symlink will now also detect an attempt to create a dangling symlink and return ENOTSUP. (is this the correct return code)?

Currently the non-strictness of the test consists of:

1. we use a separate subdirectories subdir, subdir2, subdir3 for each test stage. This is due to the fact Windows will not remove the directory and won't allow to create a directory with the same name until the previous one has been deleted. I don't see any way of circumventing it, because the application may still try to access the directory through the unclosed file descriptor.
2. path_link will return EACCES instead of EPERM when trying to create a link to a subdirectory. This violates the POSIX spec. We could manually check if the source path is a directory in case of ERROR_ACCESS_DENIED but this would cost us an extra syscall.
3. Tests for dangling symlinks or symlink loops have been disabled. Alternatively, we could check if the attempt to create a dangling symlink returns ENOTSUP, but this doesn't make much sense while 1&2 are an issue.

Let me know what you think.

Btw. @kubkon, according to this stackoverflow post Mac OS X 10.5+ permits hard links to directories, which our tests expect to fail.

---

Notes about links and symlinks under Windows:

• creating a symlink requires administrative privileges (SeCreateSymbolicLinkPrivilege). On Windows 10 this requirement may be removed, but this requires enabling developer mode
• Windows distinguishes between file and directory symlinks
• It's possible to create a dangling symlink, but the type (file/directory) has to be specified upon creation. The behavior in case of type mismatch is inconsistent. Precisely, suppose that a dangling file symlink is created foo -> bar and later, a directory bar is created. Then:
  • under msys64 bash, cd foo succeeds and the directory view is the same when access either directly or through the symlink
  • under cmd (both windowed and as a child process from msys64 bash). cd foo fails with The directory name is invalid

Wasmtime GitHub notifications bot (Apr 02 2020 at 21:09):

kubkon submitted PR Review.

Wasmtime GitHub notifications bot (Apr 03 2020 at 19:24):

marmistrz merged PR #1199.

Last updated: Dec 23 2024 at 13:07 UTC