The functions returning null or the class property is set explict null
Found by phan strict checks
Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
$wgShellLocale was a flawed solution to the problem of locale
dependence. MediaWiki has its own concept of locale (the Language
hierarchy) and any kind of dependence on the server's libc locale is
incorrect and harmful, leading to bugs. Developers have an expectation
that functions like strtolower() will work in a certain way, and
respecting the locale set in the environment at install time violates
this expectation.
The problems with using C as a locale, which led to $wgShellLocale, are:
* escapeshellarg() will strip non-ASCII characters. This can be worked
around by not using it. The security vulnerability it was trying to
fix can be prevented in another way.
* Shell commands like rsvg will fail to correctly interpret UTF-8
arguments. This is the reason for the putenv(). On Linux, this can
be fixed by using C.UTF-8, which we didn't know at the time. On
Windows, the problem is not relevant (there are unrelated issues
with UTF-8 arguments).
Bug: T291234
Change-Id: Ib5ac0e7bc720dcc094303a358ee1c7bbdcfc6447
FileBackend::getFileList() is supposed to return an empty array when the
specified path does not exist, however this was broken on Windows due to
a difference in the exception message raised by DirectoryIterator.
Unit tests and code inspection showed that there were several other
instances of unmatched Windows error messages, which I also fixed. Now
FileBackendIntegrationTest passes on Windows.
It was also broken when $wgShellLocale is set to a non-English locale.
Recommend against this in the default LocalSettings.php. Work around
the issue using socket_strerror() if available. I was able to confirm
the bug and the fix using the existing tests.
Bug: T265778
Change-Id: I2b4cfbb1554d9e05cce53513f4b474064fb57de5
* Only call FileBackend::clearCache() only specific file paths.
Make FSFileBackend respect specific path lists in doClearCache().
* Detect FSFileBackendList errors during initialization rather than
doing additional stat calls beforehand.
* Simplify FSFileBackend::doPrepareInternal() by removing is_readable()
check as well as is_writable() when mkdir() was just successfully run.
* Simplify FSFileBackend::isPathUsableInternal() to just look at the
parent directory (more likely to exist and be cacheable). Since files
are renamed into place, there isn't much need to sanity check the
target file path itself.
* Add a process cache for "usable directories" to FSFileBackend.
* Use is_dir() in TempFSFile to avoid triggering access() syscalls
each time.
Change-Id: Ib2c76f4c4117b9beffd89370498aa57b5972f167
Avoid latency of more race-condition prone is_file() calls.
Make the create/store/copy operations stream the file to a temp file
on the same device as the destination and then rename the temp file
over the destination file on success.
Use fopen() with stream_copy_to_stream() to avoid weird NFS copy()
bug and to be able to check the size properly without worrying about
race conditions since fstat() will be for the same inode that fopen()
worked on, even if the file was renamed over in the middle.
Since all operations to the "real" files happen via rename()/unlink()
or some script using the same underlying FS methods, this means that
FSFileBackend has isolation and atomicity closer to SwiftFileBackend
for these files.
Refactor the FSFileOpHandle/doExecuteOpHandlesInternal() chmod logic
to be in one place. Replace variables named $path with clearer $fsPath.
Change-Id: Ie07ec930b5cd2bcfea7b5aca11f6a667c6928e56
Bypass the calls in Windows to avoid the stat overhead. The file system
will almost always be NTFS, in which case it can't do anything since the
ACL model is totally different than that of Unix.
Add chmod calls to the existing command in FSFileOpHandle rather than
doing them all serially afterwards.
Use AtEase class for more simple error suppression cases.
Change-Id: Ib4fae9a1bf64c1a9dfde8debe724556633a5532c
Add more result constants and split up FileBackend::UNKNOWN for
clarity. This follows up 5719815f3b, which added that constant.
Make internal FileBackendStore::doGet* methods distinguish I/O errors
from missing files; the return types of public FileBackend methods are
unchanged. Avoid process caching any mtime/size/sha1 values in the
case of I/O errors. Use error constants consistently for stat methods
when given invalid paths.
Also:
* Factor out FileBackendStore::processCacheAndPersistStatEntries() method
to reduce significant code duplication.
* Consolidate duplicated isPathUsable() checks in FileOp subclasses to
FileOp::precheck().
* Remove null process cache value check from FileBackend::getFileStat()
as null values are never stored in the process cache to begin with.
* Reformat some oddly wrapped lines to look cleaner.
Change-Id: Id0e4b0da0bb2ed3184847b35142d587c7f3d953d
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
On PHP 7.1 and later, filesystem functions on Windows
use the Unicode system functions, which makes our file
handling work for non-ASCII file names.
Previously this was blacklisted for Windows on all PHP
versions. Versions before 7.1 will still reject Unicode
filenames with non-ASCII chars.
Bug: T3780
Change-Id: I94377faa5185f133be2dfb7b9b6aeacbd582834f
