- correction spelling of suppress_error
- improved error handling in remove() based on functionality in get_fileattr() and somewhat changed error handling in get_fileattr() itself
- call explicitly LLFile::fopen() to make sure we use the correct file path conversion under Windows
Removing Flawfinder comments since Flawfinder isn't used in the viewer anymore
Adding an option to support symlink detection in getattr()
Adding comments to function implementation to indicate that they are really static functions of the LLFile class
* APR_DECLARE_STATIC and APU_DECLARE_STATIC gets already defined in APR.cmake
* Move both _CRT_SECURE_NO_WARNINGS and _WINSOCK_DEPRECATED_NO_WARNINGS definitions to 00-Common.cmake
* Always define WIN32_LEAN_AND_MEAN and include subset of Windows API by default
* Remove llwin32headerslean.h and remove unnecessary WIN32_LEAN_AND_MEAN definition handling in llwin32headers.h
* Clean up includes of Windows API headers
* Get rid of workaround to link against IPHLPAPI.lib in lluuid.cpp - this seems to have been an issue in the past that has been fixed
Use LLStringUtil::getenv() or getoptenv() whenever we fetch a string that will
be used as a pathname.
Use LLFile::tmpdir() instead of getenv("TEMP").
As an added extra-special bonus, finally clean up $TMP/llcontrol-test-zzzzzz
directories that have been accumulating every time we run a local build!
On Windows, when logged in with a non-ASCII username, every one of the three
documented APIs -- SHGetSpecialFolderPath(), SHGetFolderPath() and
SHGetKnownFolderPath() -- fails to retrieve any pathname at all. We cannot
account for the fact that the oldest of these continues to work with the
release viewer and within a Python script (though not, curiously, from a
Python interactive session). With a non-ASCII username, they consistently fail
when called from an Alex Ivy viewer build: "The filename, directory name, or
volume label syntax is incorrect."
Empirically, with a non-ASCII username, the preset APPDATA and LOCALAPPDATA
environment variables are also useless, e.g. c:\Users\??????\AppData\Roaming
where those are, yup, actual question marks.
Empirically, the VMP is able to successfully call SHGetFolderPath() to
retrieve both AppData\Roaming and AppData\Local. Therefore, we make the VMP
set the APPDATA and LOCALAPPDATA environment variables to the UTF-8 encoded
correct pathnames. Instead of calling SHGetSomethingFolderPath() at all, make
LLDir_Win32 retrieve those environment variables.
Make LLFile::mkdir() treat "directory already exists" as a success case. Every
single call fell into one of two categories: either it didn't check success at
all, or it tested specially to exempt errno == EEXIST. Migrate that test into
mkdir(); eliminate it from call sites.
Make LLDir::append() and add() convenience functions accept variadic
arguments. Replace add(add()...) constructs, as well as clumsy concatenations
of directory names and getDirDelimiter(), with simple variadic add() calls.
and open() methods. The only remaining value added by ll[io]fstream over
std::[io]stream is proper handling of non-ASCII pathnames, which can be done
by deriving from std::[io]stream, converting pathname strings and passing them
to the corresponding base-class methods.
This is only necessary on Windows. On Posix, ll[io]fstream are already
typedefs for std::[io]fstream.
This change removes a significant volume of cruft from llfile.{h,cpp}.
To be more accurate, this changeset doesn't actually eliminate the dependency:
it eliminates the use cases for the llifstream / llofstream feature that
requires it.
Currently you can construct an llifstream or llofstream from an open LLFILE*
file handle (or, except on Windows, an int file descriptor). But rather than
containing a streambuf implementation based on FILE*, llfile.h relies on the
fact that the Windows std::filebuf happens to support that as a nonstandard
extension; also on a nonstandard GNU extension __gnu_cxx::stdio_filebuf<char>.
To move from GNU libstdc++ to clang's libc++ (the direction on Mac), we could
code a streambuf that supports FILE*. But before doing that, it's worth asking
whether anyone actually uses this questionable feature.
In fact there were only two methods: LLWearable::exportFile() and importFile()
-- and only one call to either, in LLViewerWearable::saveNewAsset(). The code
in saveNewAsset() opened the LLFILE* immediately before calling exportFile(),
meaning we could reasonably push the open operation down into exportFile().
That logic was complex anyway due to the need for the caller to close the
LLFILE* regardless of the success of the exportFile().
Change LLWearable::exportFile() and importFile() to accept a std::string
filename rather than an open LLFILE*. Change LLViewerWearable::saveNewAsset()
to simply call exportFile(filename) rather than horsing around with an LLFILE*
handle. (This improves the code in another way too: it encapsulates the need
to open the relevant file in binary mode. Previously, each caller had to
remember to do that.)
To prevent inadvertent reintroduction of ll[io]fstream(LLFILE*) code, add
llstream_LLFILE preprocessor macro (default 0) to control access to the
relevant constructors. Also suppress rdbuf() override, the only method whose
signature references llstdio_filebuf.
Integrated Nicky Dasmijn's patch to handle the unicode file paths properly.
Code reviewed, patch was clean.
Tested locally, correctly allows wearables to load where they would fail before.
Should be ready for automated build & QA.
Ansariel