Closed mvorisek closed 4 years ago
I don't give a shit about Windows. We may consider adding a warning in INSTALL file, that's it. I'll not spend time on this issue.
The fact that it is a first complaint about it in 10 years since we use symlinks means something.
Would it be possible to:
rm -R vendor/bin/
in the release scriptpublic_html/
Where are the symlinks from public_html/
used? In Windows the symlinks are not created and the RC seems to be working fine.
The fact that it is a first complaint about it in 10 years since we use symlinks means something.
On other platforms the symlinks are often disabled in webserver config and it seems that there are just some leftover from old times and I found it just by coincidence...
Would it be possible to:
- simply
rm -R vendor/bin/
in the release script
No, we're using these scripts
* delete & commit all symlinks in `public_html/`
No, what do you mean "delete & commit"?
On other platforms the symlinks are often disabled in webserver config and it seems that there are just some leftover from old times and I found it just by coincidence...
There are no leftovers in the package
Windows does support symlinks on NTFS, it's just that you need administrative privileges for creating them which is what WinRAR even tells you. Edit: Windows 10 Creators Update introduced the ability to create symlinks as non-administrator as well, applications must use the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag when calling the CreateSymbolicLink API which WinRAR probably does not do. Also, enabling symlinks in Apache is possible.
The purpose of the symlinks in public_html is if you make public_html the document root of your VHost in Apache. Your Roundcube installation works because you probably have the root Roundcube folder set as your document root.
I added note to the INSTALL file.
I don't give a shit about Windows. We may consider adding a warning in INSTALL file, that's it. I'll not spend time on this issue.
This is certainly not the tone with which you can solve problems. More like the opposite. I'll spare you with data on market shares and probabilities of offending or excluding people with that statement.
I also just noticed this problem when unpacking the complete archive of v1.4.9 with 7-Zip. I never noticed this before but older archives I still have here show the same warnings now. Maybe those symlinks were simply ignored or resolved in previous versions of unpackers or I used another unpacker (unlikely).
So now the INSTALL file doesn't explain anything but simply points to this issue. And this issue doesn't explain anything but show disinterest in platform support. I'm left with an open question: Can I ignore these links or are they required for something?
PS: Oh and that note in the INSTALL file is useless if users come from that page: https://github.com/roundcube/roundcubemail/wiki/Installation Windows and 7-Zip are explicitly mentioned there, probably by more tolerant authors.
Again, symbolic links are supported under Windows with NTFS. WinRAR for example tells you exactly what you have to do, that is, launch it as administrator to support creating those symbolic links. People just have to read the messages they are being displayed.
I'm not looking for a solution that involves enhanced privileges that are not found in every environment.
Still, the question remains open: Are the files and directories related to those unknown links relevant or can they safely be ignored?
It depends what you set as your document root.
Nothing, just leave the defaults. The application is in its own subdirectory, so setting a document root does not apply here.
Then you can ignore the errors. If you were to set the document root to public_html
, that wouldn't work without the symlinks.
Symbolic links are not normally supported on Windows, see release extraction log:
Symbolic links are often also disable in Apache config.
Analyse if the symbolic links are used and remove them or replace them with another solution.