WampServer

UPDATE: it appears a particular directory has an issue. I don't have a solution for that particular directory, but a newly created sibling directory works find and I've moved my working files into that new directory, which works around the problem. See post #9 for more details...

Hi, I've successfully installed and run (green icon) 3.1.3 x64, and tested PHPInfo and PHPMyAdmin to confirm that PHP is successfully executing scripts. I've also created some simple test php scripts in the default /wampserver/www directory and had those execute successfully. So far so good.

My issue (which may not be wampserver-specific) is that I can't execute php scripts from either an aliased directory or a linked (JUNCTION) directory. Instead my browser (both Vivaldi and Chrome, so not browser-specific) downloads the php file instead of executing it. Some examples, where www/ is the default directory and alias/ is the directory either aliased or linked:

1. www/test.php => executes as expected
2. alias/test.php => downloads instead of executing
3. alias/test.html => renders correctly
4. alias/test.txt => loads and display text file correctly

My takeaways:
a: php is installed and working correctly, at least as far as the default www directory is concerned, per test #1
b: My alias and my junction are also working correctly insofar as html files in those directories are loading and I'm not getting 404 or File Not Found messages, per tests #3 and 4
c: I'm satisfied that my JUNCTION is working as I can browse between as expected in File Explorer with the path correctly showing as a sub-directory of the www directory.
d: Case is not an issue - everything is lowercase for testing, and again, the files are found, just not executed.


Any ideas? And if the answer is "this isn't a WampServer problem", that's good as well - I'll go ask on StackOverflow, just thought I'd try here first.

Thanks!
Jim



Edited 1 time(s). Last edit at 05/11/2018 04:02AM by jabrooks.

Hi,

There is a subtle difference between symbolic links and junctions.

The two may seem identical, but this is not really the case. Seen via the Windows file explorer, we have the impression that it is the same thing, because we see well the tree structure of a folder and all the files which are there.
But there is an important difference that I will have some difficulty explaining in a language that is not my native language.
Via a symbolic link on a folder, the software will fetch the files where they really are, via the "redirection" of the symbolic link.
Via a junction, the software "thinks" that the folder is the junction, it is exactly as if the "real" folder is at the place of the junction.

Let us take an example.
In the folder I:\temp\ I create a symbolic link named "linkone" as well as a junction named "juncone" on the folder g:\www\phottello\ which is one of my local sites.

If you do a dir /al command in the I:\temp folder from the command line, you can see that they are two different entities:

i:\Temp>dir /al
 Le volume dans le lecteur I s'appelle SATA_1_I
 Le numéro de série du volume est 5FDF-B64A

 Répertoire de i:\Temp

29/04/2018  13:24    <JONCTION>     juncone [G:\www\phottello]
29/04/2018  13:23    <SYMLINKD>     linkone [G:\www\phottello]
               0 fichier(s)                0 octets
               2 Rép(s)  70 591 741 952 octets libres

i:\Temp>

Now I'm gonna create two VirtualHost, one with DocumentRoot "i:\Temp\linkone" and the other "i:\Temp\juncone".

The http accesses by Firefox or Opera on these two VirtualHost work correctly and the PHP code is well interpreted in both cases and there is no difference in access time in the Apache log files.
Your problem is not caused by the use of symbolic links or junctions.

---------------------------------------------------------------
Documentation Apache - Documentation PHP - Documentation MySQL - Wampserver install files & addons

Thanks for the info, I haven't played with symlinks on Windows much. I've created both types, and I see the difference when doing dir /al as you mentioned. In my case, it appeared that creating a junction would be the better choice.

Following your example, I created several virtual hosts - one using my Junction as the DocumentRoot, the other using the canonical path as the DocumentRoot:

<VirtualHost *:80>
ServerName wgdc2
DocumentRoot "f:/files/webs/wg-bootstrap"
<Directory "f:/files/webs/wg-bootstrap/">
Options +Indexes +Includes +FollowSymLinks +MultiViews
AllowOverride All
Require local
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerName wgdc3
DocumentRoot "d:/wamp64/www/wgdc2" #wgdc2 is a Junction to the same folder as the wgdc2 virtual host above...
<Directory "d:/wamp64/www/wgdc2/">
Options +Indexes +Includes +FollowSymLinks +MultiViews
AllowOverride All
Require local
</Directory>
</VirtualHost>


Both hosts fail to execute PHP in the same manner as using the Alias or simply specifying the Junction in the URL. Simple HTML is fine in this directory, while PHP downloads instead of interpreting the file. Obviously I have a config problem somewhere. Very frustrating, though I'm sure very simple when I figure out what's wrong. As you mentioned, it doesn't appear to be browser-related as Vivaldi, Opera, and Chrome all work identical (Edge refuses to see the virtual hosts at all, but I can live with that as I never use Edge anyway)

The easy answer, of course, is that I simply copy my working folders over to the d:\wamp64\www directory, that that puts my working files on the same drive as my applications, something I weaned myself off of almost 20 years ago and really want to avoid if at all possible.

Junction and symbolic links.
In theory, the major difference is that the symbolic link can target a local or remote folder (UNC, via network share/SMB ) then that the junction is local disk only.
Used locally, I don't see any big difference on the practical side, except handling of disks by more or less specialized softs, in particular attention to the interpretation/follow up of these various links by a software of backup, with some one can risk either the double of backup or the omission of a complete tree structure.

However, when used in a network there is a big difference.
The symbolic link is processed by the client not the file server (NAS), it imposes some notable points :
- activate symbolic link processing "via network" on the client workstation, which is disabled by default on Windows workstations (only "local to local" and "local to network" links are enabled by default.
- This feature is not very / not usable by by clients using an SMB client not equipped with all the features (Mac/Linux), it is even more sensitive if you use SMB v2 or v3 and even more with DFS, so unless you are in client workstations 100% Windows Vista or +, you risk having client workstations that do not access everything.
- the target should be accessible to the client, it must be a UNC path whose name can be resolved and whose path contains the ACL needed for the client to access the target.

The NTFS file junction, on the other hand, is processed at the FS access level on the server, a junction placed in a share is seen or processed by the server, the client sees nothing special and accesses it just like an ordinary subfolder.
Personally, in local/local, I privilege the junction of file on the symbolic link, it is treated closer to the FS by the OS and less subject to bizarre behavior on the part of the softs which turn on the PC.
A bit (a lot) of good reading on these topics and a nice software to see/play with :
Link Shell Extension
http://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

---------------------------------------------------------------
Documentation Apache - Documentation PHP - Documentation MySQL - Wampserver install files & addons

Hi,

May be junction or symlink cannot be followed because its type is disabled with your Windows.
See :
https://blogs.msdn.microsoft.com/junfeng/2012/05/07/the-symbolic-link-cannot-be-followed-because-its-type-is-disabled/

To see how symbolic links are supported by your system, in a command window opened as an administrator, type :
fsutil behavior query SymlinkEvaluation

The different modes can be supported, again by commands in a command window like :

fsutil behavior set SymlinkEvaluation XXXX

with XXXX = [L2L:{0|1}] | [L2R:{0|1}] | [R2R:{0|1}] | [R2L:{0|1}]
L2L = Local to Local
L2R = Local to Network
R2R = Network to Network
R2L = Network to Local
:1 activate
:0 descativate

---------------------------------------------------------------
Documentation Apache - Documentation PHP - Documentation MySQL - Wampserver install files & addons

I truly appreciate the time you're spending with me on this -

For background, this is my personal workstation, all drives are separate physical and local drives, no network/remote connections. Running fsutil doesn't show any issues with my setup, as I would expect since I can see the symlinks, query them, follow them, and run HTML and TXT files from them:

D:\wamp64\www>fsutil behavior query symlinkevaluation
Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.

I thought perhaps it was a permissions issue, but I've checked permissions through the security tab for the symlink, the root directory, and the php file (all had execute permissions already), and even gone so far as to give everyone full rights. No difference.

Frustrating.

OK, update:

I created a NEW directory off the root of my files drive, named F:/test, and copied two files into it named index.html and test.php (the same two files I've been using). I created a new alias to that directory (f-test, short for "drive F test", and the php file executed correctly!

So, more troubleshooting to do: Apache/php is apparently not happy with my original directory (f:/files/webs/wg-bootstrap), either because of the name (length, hyphen in the directory name?) or some sort of permissions issue somewhere in the path.

BUT at this point, I can at least leave my files on my preferred drive even if I have to put them in a different folder, so I'm not completely unhappy. I'll experiment some more with directory names and permissions and update this for the record if/when I figure out the issue.

In the meantime, at least I can get back to work on my coding rather than working on tools :^)

Hi,

I too am trying to understand where the problem might come from in order to perform additional checks when Wampserver is launched.

---------------------------------------------------------------
Documentation Apache - Documentation PHP - Documentation MySQL - Wampserver install files & addons

A follow-up for the record: I don't have an answer to the problem, but do have some test results for others to see. I'm stumped and moving on.

TEST NOTES:

1. In all these cases, FAIL means the file ends up being copied to my download folder rather than executing/rendering. WORKS means I see the single word "Success" in my browser, indicating the file executes.

2. I'm using the same simple PHP file copied to different locations - file is a simple "<?php echo("Success" ); ?>"

3. It's only PHP files that are a problem. HTML and TXT files seem to work correctly.

4. It's not browser-specific - happens in Edge, Chrome, IE, Opera, and Vivaldi.


RESULTS:

It appears to be this specific directory that has a problem {F:\files\Webs\wg-bootstrap 2016}

1. PHP file created in or copied to this directory FAILS to execute.

2. Same file copied to child directories below this one FAIL.

3. Same file copied to the parent directory or other directories WORKS

4. Making a simple copy (ctrl-drag/drop) of this directory FAILS as in test 1. Didn't try a CLI copy, didn't see the point. Hmm, maybe an xcopy /t might be interesting....

5. Making a new directory and copying all contents into the new directory WORKS

6. Alias, VirtualHost, or Symlink makes no difference - they all work or fail the same way.

7. Claiming ownership of the directory and/or contents has no impact. I already had ownership, just thought something might be screwed up.

8. Resetting all permissions to FULL has no impact. I already had adequate R X permissions, just being thorough.


At this point, I'm stumped and moving on, since I can copy my working files into a new directory without issue. Wish I had an answer, and if anyone has thoughts I'll try them. In the meantime, I'll chalk this one up to something not obvious and get back to my paying job :^)