SQL Server - SMSS - Solution to .bak file not visible in any other directory in SSMS

Try to restore a database in SQL Server 2012 R2 (but this does not matter), and ran into same old issue of not being able to find a SQL Server backup (.bak) in a directory, that was not the default (C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup) directory for back-up files. 

In my example, the .bak file was in C:\build

Of course it's a permissions on the file right? 

So launch SQL Server Configuration Manager (SSCM) to get the account that SLQ Server is running under and copy the Account Name.

In this case, copy Account Name which is  "NT Service\MSSQL$SQLENT2012"

Adding the service account is not as straightforward.

1. Log into the server. (The change must be made on the actual server, not through a network share.)
2. Change the Locations to the local server name, not an Active Directory account. 
3. Paste in NT Service\MSSQL$SQLENT2012 in the name box. (Do not click Check Names)
4. Click OK. You will then see a list of the matching service accounts. Select MSSQLSERVER, and click OK to accept the selection.
   
   
5. Which then looks like the following when done. Success right?
   
   
   
6. Open the directory in SQL Server Management Studio (SSMS) what blank ?
   
   
   
    
7. What if I just copy the file to default directory C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup
   
   
8. Check permission of this file in default. They are the same!
   
   
9. Then it dawned on me,  the directory C:\build does not have any permissions assigned to "NT Service\MSSQL$SQLENT2012".
   
   
10.  SOLUTION
    
    It's a file and FOLDER permission issue. All solutions I have seen on Stack Overflow/Exchange forget the fact if you have a existing folder you have to apply the service account of SQL Server (use SSCM to find) to each FOLDER in the full path.
    
    So you have to the cascade the account user and set permissions down each directory ;) as well.

WordPress Some URL parameters are empty on POST or GET

How to fix empty URL Parameters on Post or Get in WordPress

Parsing URL parameters in WordPress and they are appearing empty it's most likely an issue with your .htaccess file.

Start with default WordPress .htaccess file from https://wordpress.org/support/article/htaccess/

Add the following line  RewriteRule "/users/([0-9]+)/?" "/users?page=$1" [QSA]

1 2 3 4 5 6 7 8 9 10 11 12 13

# BEGIN WordPress RewriteEngine On RewriteBase / RewriteRule "/users/([0-9]+)/?" "/users?page=$1" [QSA] RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress

The key to this fix is the QSA flags, see below for full explaination. 

Understand Apache RewriteRule Flags - http://httpd.apache.org/docs/current/rewrite/flags.html#flag_qsa

QSA|qsappend

When the replacement URI contains a query string, the default behavior of RewriteRule is to discard the existing query string, and replace it with the newly generated one. Using the [QSA] flag causes the query strings to be combined.

Consider the following rule:

RewriteRule "/users/([0-9]+)/?" "/users?page=$1" [QSA]

With the [QSA] flag, a request for /users/123/?fullprofile=true will be mapped to /users?page=123&fullprofile=true. 

Without the [QSA] flag, that same request will be mapped to /users/123/?fullprofile=true - that is, the existing query string will be discarded.

Linux maintains bugs

In many operating systems, there are two parts - the userland (user space) and kernel space. In Linux, the userland is GNU. Applications reside in the userland while the Linux kernel (and most drivers) reside in the kernel space. GNU is an open-source userland that contains many applications and utilities. The GNU Project is a programming collaboration for the GNU userland and related GNU software. 

As this post* points out, these two can get out of sync very quickly and you have breaking dependencies, which restrict kernel bugs from being fixed.

*https://blog.farhan.codes/2018/06/25/linux-maintains-bugs-the-real-reason-ifconfig-on-linux-is-deprecated/

On Linux, because the kernel and the rest of the operating system are not developed in tandem, this means updating or fixing a kernel struct would almost guarantee to break a downstream application. The only to prevent this would be to conduct regular massively coordinated updates to system utilities when the kernel changes, and properly version applications for specific kernel releases. Quite a herculean endeavor. This also explains why systemtap, one of Linux’s many answers to dtrace(1), does not work on Ubuntu.

Also, Linux can never have an equivalent of a lib80211(3) because there is no single standard library set. Even for the standard C library set, Linux has Glibc, uClibC, Dietlibc, Bionic and Musl. Rather than guessing the underlying C library implementation or falling into “dependency hell“, applications default to the most low-level implementation or their requested functionality. Some tools, such as ifconfig(8), resort to just reading from the /proc filesystem.

Linux’s solution to this problem was to create a policy of never breaking userland applications. This means userland interfaces to the Linux kernel never change under any circumstances, even if they malfunction and have known bugs. That is worth reiterating. Linux maintains known bugs – and actively refuses to fix them. In fact, if you attempt to fix them, Linus will curse at you, as manifest by this email (see below).

In Linus Torvalds own words - https://lkml.org/lkml/2012/12/23/75

From
Linus Torvalds <>
Date
Sun, 23 Dec 2012 09:36:15 -0800
Subject
Re: [Regression w/ patch] Media commit causes user space to misbahave (was: Re: Linux 3.8-rc1)

It's a bug alright - in the kernel. How long have you been a
maintainer? And you *still* haven't learnt the first rule of kernel
maintenance?

If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to
understand?