Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with Non-Allow Chars in Filenames on Windows #81

Closed
budgetneon opened this issue Mar 13, 2016 · 17 comments

Comments

@budgetneon
Copy link

commented Mar 13, 2016

Trying to help someone on the opencart forums here:

http://forum.opencart.com/viewtopic.php?f=183&t=159432

Somehow, vqmod is trying to create a file with a name that has a colon (:) in it. That won't work on Windows, as there are some characters not allowed in a filename.

@qphoria

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

That was a bug in 2.6.0. Get 2.6.1
On Mar 13, 2016 11:22 AM, "Budget Neon" notifications@github.com wrote:

Trying to help someone on the opencart forums here:

http://forum.opencart.com/viewtopic.php?f=183&t=159432

Somehow, vqmod is trying to create a file with a name that has a colon (:)
in it. That won't work on Windows, as there are some characters not
allowed in a filename.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx#naming_conventions


Reply to this email directly or view it on GitHub
#81.

@chrisdempsey

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

It is 2.6.1 that's installed: $_vqversion = '2.6.1';

Any chance you could take a look through the Opencart forum post linked above and advise if you can point me in the right direction?

@budgetneon

This comment has been minimized.

Copy link
Author

commented Mar 13, 2016

Basically, it's the call to realpath() that's introducing a colon back in...because realpath() returns things like 'C:\whatever\whatever' on windows. Vqmod has underscores as placeholders for path separators, but no placeholder for the leading 'c:', 'd:', etc. Not sure it's an easy fix, php kind of boxes you in with realpath().

@qphoria

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

But I developed this on a windows machine and I do not have the same issue.

Cheers,

Tom "Qphoria"
OpenCartGuru.com

On Sun, Mar 13, 2016 at 11:54 AM, Budget Neon notifications@github.com
wrote:

Basically, it's the call to realpath() that's introducing a colon back
in...because realpath() returns things like 'C:\whatever\whatever' on
windows.


Reply to this email directly or view it on GitHub
#81 (comment).

@JAY6390

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

What server are you running? IIS?

@chrisdempsey

This comment has been minimized.

Copy link
Contributor

commented Mar 13, 2016

Experiencing issue on IIS8.

All versions up to 2.5.1 ran successfully on previous server with IIS7.5.

Edit - should also say the reason I changed various versions of vQmod across each of the OpenCart sites to 2.5.1 is none of them worked on the new server.

This indicates a different configuration on the new server but I can't figure what it is.

@chrisdempsey

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2016

Think this is solved.

Short version
Changing line #120 of vqmod.php from

$stripped_filename = preg_replace('~^' . preg_quote(self::getCwd(), '~i') . '~', '', $sourcePath)

to

$stripped_filename = preg_replace('~^' . preg_quote(self::getCwd(), '~i') . '~i', '', $sourcePath);

Means the /vqmod/vqcache/vq2-*.php cache files are written and the website runs as normal.

Long version
Breaking down line #120:

  • [list]self::getCwd() is returned as: C:\Net\hosts\domai... etc.
  • $sourcePath is generated by self::_realpath($sourceFile); and is returned as: C:\net\hosts\domai... etc.
  • function _realpath() sets $path = realpath($file);

So when preg_quote tries to create $stripped_filename it can't find an exact match because for case-insensitive filesystems realpath() may or may not normalize the character case.

Since Windows is case insensitive I guess this is where the problem lies.

However, I am unsure why only the first letter in the path is affected.

The absolute root directory is C:\Net which $sourcepath returns as C:\net.

If sub folders have upper case letters they are returned as such.

I guess the reason there was no issue on the original server is the absolute root directory happens to be C:\net.

I'll test further with additional sites tomorrow.

Can anyone advise how Linux systems would react to the change to line #120 noted above?

I tested very briefly on a site on the old server and it looks to behave as normal.

I'm wondering if a pull request should be submitted?

@JAY6390

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2016

Hi Chris

Don't have time to test this just now on a linux install, but from that line I notice the i you add may well need to be there, and the i in the preg_quote function defintely shouldn't be there (i.e. the first ~i should be ~

Kind regards
Jay

@qphoria

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2016

Well I do use windows and don't see this problem, but I also don't use IIS.
Still this must be something new in IIS 8 as the vQmod code for realpath
hasn't changed in 2 years.
Then again.. if you are using IIS you should probably be taken out and shot
anyway

Cheers,

Tom "Qphoria"
OpenCartGuru.com

On Sun, Mar 13, 2016 at 9:38 PM, JAY6390 notifications@github.com wrote:

Hi Chris

Don't have time to test this just now on a linux install, but from that
line I notice the i you add may well need to be there, and the i in the
preg_quote function defintely shouldn't be there (i.e. the first ~i
should be ~

Kind regards
Jay


Reply to this email directly or view it on GitHub
#81 (comment).

@chrisdempsey

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2016

The i in preg_quote was introduced in v2.4.1

$stripped_filename = preg_replace('^' . preg_quote($this->getCwd(), '') . '', '', $sourcePath); // 2.3.2
$stripped_filename = preg_replace('
^' . preg_quote(self::getCwd(), 'i') . '', '', $sourcePath); // 2.4.1

The i in preg_replace definitely needs to be there for my environment.

I assume it relates to IIS8 rather than PHP 5.3.29. Will find out shortly as I need the sites running on PHP 5.4 or 5.5 to take advantage of Wincache.

If necessary, perhaps in future releases the $windows flag could be used to switch between patterns '~' and '~i'if Linux wasn't happy with it being a permanent feature. Probably shouldn't be as it would cause the same problem in reverse if two directories existed with the same name and different case.

Or a note in the readme.txt in case anyone else is on IIS.

Was forced into IIS by an employer years ago. Now I'm too heavily invested in the platform to uproot.

@JAY6390

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2016

Hmm, the i should be after the last ~, i.e.

$stripped_filename = preg_replace('~^' . preg_quote(self::getCwd(), '~') . '~i', '', $sourcePath);
@chrisdempsey

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

I only left the first i in because it's in the original code.

Guess it's possible the original author intended to place it after the last ~ but since Linux has a case sensitive filesystem I'm not sure they would deliberately make the preg_replace case insensitive.

Main thing this is documented now so anyone that experiences it on IIS in future might find the resolution quickly.

@JAY6390

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

Hi Chris

Yeah I wrote the original and it definitely wasn't meant to be there - though how it's been overlooked for a couple of years I don't know 😄. The insensitive was actually due to windows if I recall correctly and it's only on the cwd value so not all that important for sensitivity. The chances of someone having two directories with the exact same path but a case difference is very unlikely

@chrisdempsey

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

I'm sure that'll be because I'm the only one running it on IIS.

Do you mind if I submit a pull request with the correction? I've only contributed directly to one other repository so could use the practice.

@qphoria

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2016

Yes give it a try. We could use the practice with pull merges as well :)

Cheers,

Tom "Qphoria"
OpenCartGuru.com

On Thu, Mar 17, 2016 at 10:54 AM, Chris Dempsey notifications@github.com
wrote:

I'm sure that'll be because I'm the only one running it on IIS.

Do you mind if I submit a pull request with the correction? I've only
contributed directly to one other repository so could use the practice.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#81 (comment)

@howdu

This comment has been minimized.

Copy link

commented May 21, 2017

I've been getting the same issue on windows the opencart branch still references 2.6.0. Downloading 2.6.1 from tree fixed issue.

@susanlummis

This comment has been minimized.

Copy link

commented May 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.