Hi! I´m a teacher from spain, my currently my students are trying to learn swift with windows but it doesn't finish compiling, could you help me?
They have a windows 11 pc
Hi! I´m a teacher from spain, my currently my students are trying to learn swift with windows but it doesn't finish compiling, could you help me?
They have a windows 11 pc
There really isn't anything there that is actionable. "Doesn't finish compiling" could mean a variety of things (does it fail? hang? take too long to compile?). There is no sample code to reproduce the issue either. Could you share more details about what the issue is that you are facing, what you have tried, and how to reproduce it?
Here are the problems:.
print("¡Hola, mundo!")
PS C:\Users\Admin> swift run
Building for debugging...
Build complete! (0.12s)
warning: unable to create symbolic link at C:\Users\Admin.build\debug: Error Domain=NSCocoaErrorDomain Code=256 "(null)"
Hello, world!
The error message is rather helpful here :). You have not granted the user the SeCreateSymbolicLinkPrivilege
privilege which prevents the creation of symbolic links. An alternative is to enable "Developer Mode" which will reduce security on the system if you prefer. There are plenty of guides online on how to use SecEdit to modify the GPO to grant the rights.
There are plenty of guides online on how to use SecEdit to modify the GPO to grant the rights.
Wow, I am not finding any simple explanations of what to do when I search for that. It appears I am an Administrator and according to SECPOL.MSC, that privilege is granted to "Administrators". So why am I getting this warning and what do I need to do suppress it without opening a security hole? (Developer mode works)
@NeoNacho And why is it just a warning, if nothing works when it happens?
security - Permission to make symbolic links in Windows 7? - Super User is one of the first hits on Google for me. I think that is pretty accurate as to what needs to be done. IMO it is better than developer mode as it reduces the size of the "hole" here (basically the hole introduced is that you can create symbolic links now).
As to why you need to do this is that the default policy is not permit creation of symbolic links (because they are considered "a security vulnerability" as they could theoretically change permissions ... Unix has had this functionality for ages yet I don't think it is ever considered a threat or I must've missed that memo. citation: Create symbolic links - Windows Security | Microsoft Learn [/rant]). Although your user may be part of the administrator group, the user by default does not have the elevated privileges and would need to enter that context by using runas
to gain the elevated privilege.
NTFS has had alternate streams for 30+ years but they’re also considered a security risk because they are essentially unused for legitimate purposes, and therefore virtually no Windows programmers or users know about them.
How many CVEs in e.g. web servers can be attributed to symlink abuse on platforms that’ve had symlinks for longer than NTFS has had alternate streams? I can totally understand that symlinks are a risky introduction on Windows, even if you acknowledge the historical existence of NTFS junctions.
For directly setting the appropriate privilege (if not using the the simpler to set developer mode) see “directly setting the SeCreateSymbolicLinkPrivilege” there as the gpedit.msc is not yet installed on the Home edition of windows,
From what I could find it seems that virus scanners could be tricked when symlink can be created. Symlinks are a usual tool where otherwise you would have to copy a lot (which is space-wise not really a difference on a Mac I think because of the copy-on-write implementation in the file system), but e.g. when using Python environments (venv, conda) you can configurate if you want it “cheap” (using links) or “expensive” (copying everything for each environment), and without knowing too much about how the Swift Package Manager internally works, I think giving the user such an option (with appropriate default settings for each platforms or maybe according to the privileges) could be a good idea, making Swift usable on Windows without changing any privileges (you might then still display a warning that operations are not as fast as they could be).
IIRC Swift Package Manager doesn't actually require this privilege to work. The symlink action is for historical reasons and convenience, that the newest release and debug build directory is symlinked into .build/debug
and .build/release
, and some external tools relied on this path. That’s why I patched to downgrade this from error into warning.
However, in another patch we enabled symlink support for Git by default, to allow checking out Git repositories with UNIX symlinks correctly. This means we still require the permission for some packages. It is undesirable to ask package authors duplicate their files and directories, so we have to do that.
I've overlooked that it is now only a warning in the citation by @Dkt22. This is actually good news, as it lowers the entry for Swift, e.g. in organizations which are quite strict about security. Maybe the warning should contain more information in order not to scare people too much or explain what the downside of not enabling symlinks would be.
I guess if you do not enable symlinks and then use a repo with symlinks, the according git error is then correctly passed through (to be tested?) and that in other cases everything still works well despite the warning.
@compnerd Maybe the documentation for Windows should then be updated accordingly (the advice could still be that symlinks should be enabled, because …?).
Thanks.
The Windows guide is being refreshed at https://github.com/apple/swift-org-website/pull/385, and we’re still recommending Developer Mode at the moment (because it’s the easiest way and we don’t want to include too much technical detail in such a guide for newcomers).
The ultimate solution would be an installer option (requires UAC) to enable only SeCreateSymbolicLinkPrivilege
automatically. I think this is being investigated, but I just want to mention that such addition could possibly lead to false alarms by antivirus services…
OK, thanks. Keep in mind that for some of us, instructions for Windows 7 don't seem like a good bet on Windows 11 unless a l337 guru like u tells us it's going to work, so a little more detail than "search the web" may be needed ;-)
Currently a recommendation to enable developer mode is missing on the installation page and I think this is perfectly OK if symlinks are actually only needed if some package repository uses symlinks.
The problem is that the warning “unable to create symbolic link” is either superfluous (citation: “the symlink action is for historical reasons”) or an according problem stems from a package that uses symlinks and then the warning should be an error and would need an additional info so the user can understand what the issue is.
If the problem really only occurs with the special case of a package using symlinks, then a simple hint in an according error message (that “catches” the according Git error) that symlinks should be enabled for this package e.g. via enabling developer mode on Windows should be sufficient and then a little web search would indeed be OK.
Since the “Hello, world!” was printed everything worked fine and it was only the warning that was distracting, more so because it contained the original error saying “Error”.
Incidentally, ADS is part of the problem for DocC - :
is the ADS delimiter and the use of :
in the filename will truncate as the remaining will be the identifier the stream.
Just awaiting on someone to merge the patch(
I guess we can do a survey on how many Swift developers are actually relying on this behavior. If there's little need, we can propose to provide an environment variable to skip the action, and completely remove it in Swift 6.
Not sure what you mean, I only see one mention of the warning in this thread here and it seems like swift run
works fine despite of it? What's the scenario where not being able to create the build directory symlink is fatal?
Can I ask a slightly off-topic windows (11) question?
Are Python 3.10 and VS 2019 minimum or strict requirements? I mean, if one to use Python 3.11 or VS 2022 for example, will it still work?
VS 2022 is fine and Python 3.11 should also be fine (Python is needed for debugging).
Visual Studio is a minimum requirement, but in practice I would recommend newer (but not necessarily the latest) versions.
On the other hand, Python has a strict version requirement because we’re relying on its unstable ABI. This means you may need different versions of Python for different Swift toolchains.