When you set up Wakatime on Portable Visual Studio Code, it automatically puts the config files (.wakatime.cfg, .wakatime.db, .wakatime.log) in C:/Users/<username>. I would like these to be set in the data directory of the VS Code. When you start the VS Code in another computer, it prompts for Wakatime API key because the key was left in the other machine. How can this be accomplished?
In Wakatime's extension.js, this is explicitly specified in line 193 and 689 . I edited the second function to set the config files in data/extensions inside VS Code portable directory but would obviously be overwritten with updates. I just have to change it back after an update. Updates are less often than moving between machines so it will do for now.
getWakaHome() {
let home = process.env.WAKATIME_HOME;
if (home) {
return home;
}
else {
return this.getUserHomeDir();
}
}
getUserHomeDir() {
return process.env[Dependencies.isWindows() ? 'USERPROFILE' : 'HOME'] || '';
}
change above to getUserHomeDir()
getUserHomeDir() {
return 'data/extensions-data';
}
You can set an environment variable to specify where the wakatime files will be stored. Save this variable as $WAKATIME_HOME. It worked on Linux.
Click here to see more.
Related
I'm seeing some weird behavior when running a test install of my Qt program (tried using qt 5.5.1 and 7.0). I haven't noticed the issue when running in a debug/development environment - but see the issue when installed into "Program Files (x86)".
The issue is: I'm using QDirIterator to find database files within the "QStandardPaths::DataLocation" locations and loading them in via sqlite. The phantom files are located in Program Files (x86)//Library/.ndat What I'm seeing is that files from a previous install (which have been deleted) and ones that have been renamed, then deleted, still show up and are readable in the program. These "phantom" files have been blocking loading of the up-to-date file. It's really strange - I wonder if anyone has seen the issue?
I'm running Windows 10 Home on an SSD-based machine (if it matters). Same issue with Qt 5.5.1 and 5.7. I've replicated it on a different machine with similar configuration.
Any ideas?
Here's a summary of my code:
QStringList standardPaths = QStandardPaths::locateAll(QStandardPaths::DataLocation, "Library", QStandardPaths::LocateDirectory);
QStringList fileFilters;
fileFilters << "*.ndat";
foreach (const QString &dir, standardPaths) {
QDirIterator iterator (dir, fileFilters);
while (iterator.hasNext()) {
const QString &filePath = iterator.next();
QString databaseName = QFileInfo(filePath).baseName();
database_->open(filePath, baseName); // my function
}
}
boolDataManager::open (const QString &filePath, const QString &connectionName) {
QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE", connectionName);
db.setDatabaseName (filePath);
if (!db.open()) {
ERROR(QString("Cannot open database %1 with error %2")
.arg(QFileInfo(filePath).baseName())
.arg(db.lastError().text()));
printError();
return false;
}
databaseNames_.append(connectionName);
return true;
}
This code seems to read in files that don't exist anymore - and strangely, reads contents of old files that have been overwritten in the same spot. It only seems to happen when the files are located within the "Program Files" directory; not in a user directory or what-not.
For example, version 1 of my code had a database called "database.dat" with 10 entries. Version 2 of my install overwrote the file with a file of the same name with 20 entries. Version 2 of my code finds the database.dat file but only reads in the older version with 10 entries - Really weird!
Update
It appears that these "phantom" files are stored at:
C:\Users/USERNAME/AppData/Local/VirtualStore/Program Files (x86)/PROGRAM NAME/database.dat
My guess is that I'm opening the file in my program not as read-only so Windows creates a working copy in a user-writable location. Will investigate.
The issue is Windows caching - I think - One cant really tell with software that doesn't provide any way to debug it - such as Windows.
I've heard that this solution can also be solved (or at least decreased) by turning on the "Application Experience" Service -- I still run into it from time to time, typically when doing too many Filesystem writes in too short of a time.
I dont know exactly what the cause is -- and I'm pretty sure nobody else does or it would have been fixed.. but as far as I know there is no fix for that (as of this answer's date)
--
Here's my solution to problems like this that works 100% of the time:
To avoid this problem, append the version number to the end of your database's filename each time you compile, in fact apppend it to all your files by using a
#define VERSION 4.22.21
and then just adding .append(QString("%1").arg(VERSION)); or something.
All you have to really do then is write up some quick code to import all the necessary data from an old database or from wherever, which you should have more or less anyways just from using the database.
Better to avoid situations like that than to try and figure them out -- not to mention you now have a perfect revision system without even trying.
UPDATE
Since theres no use case, no code, and no information about the project, I would have to guess at what you were trying to do -
QList<DataDir*> dataDirectories;
DataDir* new_dataDir;
QStringList standardPaths = QStandardPaths::locateAll(QStandardPaths::DataLocation, "Library", QStandardPaths::LocateDirectory);
QStringList fileFilters;
fileFilters << "*.ndat";
foreach (const QString &dir, standardPaths) {
QDirIterator iterator (dir, fileFilters);
while (iterator.hasNext()) {
const QString &filePath = iterator.next();
QString databaseName = QFileInfo(filePath).baseName();
database_->open(filePath, baseName); // my function
/* Do your database reading or writing and save the results
* into a QHash or something then do this: */
database_->close(); // super important
}
}
After a bunch of poking around, I found the source of the problem (and solution).
Windows (for backwards compatibility) has a VirtualStore function where if the program tries to write to a unwritable file (based on permissions, e.g. Program Files/Progname/test.txt), it'll copy that file into USER/AppData/Local/VirtualStore/Program Files/.... This new file is not deleted when the program is uninstalled, but looks to the QT program as residing at its original location.
The solution is to open the Sqlite database in read only mode:
QSqlDatabase db = QSqlDatabase::addDatabase("QSQLITE", connectionName);
if (!writable_)
db.setConnectOptions(QLatin1String("QSQLITE_OPEN_READONLY"));
db.setDatabaseName (filePath);
Now, I'm running into a problem determining whether the file is writable. This:
writable_ = fInfo.isWritable();
always returns true, even for files in Program Files. Even when enabling NTFS permissions checking:
extern Q_CORE_EXPORT int qt_ntfs_permission_lookup;
qt_ntfs_permission_lookup++; // turn permisssions checking on
the permissions check doesn't work. So now I'm simply doing this:
QString appDir = gApp->applicationDirPath();
QString relFilepath = QDir(appDir).relativeFilePath(filePath);
if (!relFilepath.startsWith(".."))
writable_ = false;
Database is read only (OK for my application) and no longer creates anything within VirtualStore
I have a web application that reads files from its local directory (in wamp/www/). This file needed to be accessed by several users so I synced and shared it using Dropbox. Now, is there a shortcut I can use in php commands such as fwrite such that the code is not strictly applicable to only one computer?
For example, I can't code it to fwrite("C:\Users\name\My Documents\") because that is pretty specific to one user and long. I was wondering if there was a shorthand I can use, like %appdata% or %programfiles%?
Try using
$_SERVER['HOMEDRIVE'] and $_SERVER['HOMEPATH']
For drive and path to user folder respectively
print_r($_SERVER)
Will display all the environment variables. There you can see which one to select.
$fp = fopen("{$_ENV['USERPROFILE']}\My Documents\somefile.txt", 'wb');
See $_ENV on the manual and also getenv().
Please note this will only work in limited circumstances. You can use this internal function instead:
#include<Shlobj.h>
PHP_FUNCTION(win_get_desktop_folder)
{
char szPath[MAX_PATH];
if (zend_parse_parameters_none() == FAILURE)
RETURN_NULL();
if (SUCCEEDED(SHGetSpecialFolderPathA(NULL, szPath,
CSIDL_MYDOCUMENTS, FALSE))) {
RETURN_STRING(szPath, 1);
} else {
RETURN_FALSE;
}
}
I am writing a simple file uploader in CodeIgniter 2.0.2. Pasting code below.
Under certain conditions the browser hangs during this upload and I get "waiting for localhost" in the browser status bar (identical behavior in FF and Chrome).
I have verified that the file is being uploaded to the Windows temporary folder (the complete file), but the process gets stuck after that.
It appears that the condition for the bug is file size. But my php.ini has all the right settings for uploading files, and I still get the hang with a 700k file.
This bug occurs only when I run it on Windows 7 Apache, not on an Ubuntu box.
The suggested to me that some paths in the php.ini may be incorrectly set.
Apache log files have not been much help here because there is no error thrown.
I have tried using Chrome developer panel to debug but haven't turned up anything useful.
I am currently trying to get XDebug working, but since no error is thrown and the process doesn't complete, my expectations are low.
Any suggestions for how to trace this bug?
If there are specific php.ini settings you'd like to see, let me know, don't want to do the big dump.
Controller:
function do_upload_sql(){
// create directory
if (! is_dir(BACKUP_DIR)) {
mkdir(BACKUP_DIR, 0777);
}
// or if it exists and has restricted file permissions, change them
elseif(fileperms(BACKUP_DIR)!=0777){
chmod(BACKUP_DIR, 0777);
}
$config['upload_path'] = BACKUP_DIR;
$config['allowed_types'] = 'backup'; // an SQL backup file type
$config['overwrite'] = TRUE;
$this->load->library('upload', $config);
if ( ! $this->upload->do_upload()) // this is the native CI function, probably where the problem is. I can provide some of that code if anyone wants.
{
$data['action'] = 'c_backup_restore/do_upload_sql';
$tab_error = array('error' => $this->upload->display_errors());
$data['error'] = $tab_error['error'];
$this->load->view('common/header');
$this->load->view('v_upload_sql', $data);
}
else
{
echo "success"; // yes it's getting here, but i get no file!
$data = array('upload_data' => $this->upload->data());
$file_upload = $data["upload_data"];
$this->restore_backup($file_upload); // go do something useful with the file
}
}
View:
<p>Select the backup file</p>
<div class="not_success"><?php echo $error;?></div>
<?php echo form_open_multipart($action);?>
<input type="file" name="userfile" size="30" />
<input type="submit" value="Upload" />
</form>
If your error only occurs on windows 7 apache, I think that your issue may be with the "is_dir()" "mkdir()" and "chmod()" commands -- these terminal commands are linux specific and will not work so great on a windows system.
I looked up the documentation on the mkdir() function in the PHP.net Manual at:
http://us.php.net/manual/en/function.mkdir.php
I found this in the comments section:
kendsnyder at gmail dot com 04-May-2007 08:17
When creating directories in Windows, trailing periods (".") are ignored. for example:
<?php
mkdir('c:/Buck Jr.',0755); // on Windows creates "c:/Buck Jr"
mkdir('c:/Elipses...',0755); // on Windows creates "c:/Elipses"
mkdir('c:/php.com',0755); // on Windows creates "c:/php.com"
?>
This is a Window's quirk, not a php shortcoming--meaning that you get the same results from a Window's command prompt.
So it seems it will work... but you are likely to have to futz with it to find the flavor that Windows systems prefer. Also it seems that you must specify the root drive on which to make the directory, e.g.: 'c:\somedir'
Also of interest, I did a quick google search and discovered that PHP has published a bug around the functionality you are using, specifically related to forward vs. back slashes of the windows vs. linux systems:
https://bugs.php.net/bug.php?id=29797
Here is a StackOverflow post related to your question:
PHP mkdir(), chmod() and Windows
So to summarize:
On a windows based web server, include the drive that the directory will be placed on
File Permissions on Windows are different from Linux (Windows doesn't have a chmod or file permissions structure like Linux!) Although from what I can tell Windows is supposed give a folder the equivalent of a 777 permissions level -- but this functionality seems buggy and error prone. But this also means that using the chmod() function on a windows system, you will get unpredictable results. For more info consult the PHP Manual: http://php.net/manual/en/function.chmod.php
Remember to use backslashes rather than forward slashes for the directory path, as Windows systems use back slashes, whereas Linux uses forward slashes.
When PHP creates a directory it uses the permissions that were granted to the user account that PHP is running under, which means that you may have to dig into windows to find what user permissions level your windows 7 Apache/PHP is running under and make that change there. I know, what a pain, right?
One final thing: mkdir() function returns true if the directory creation was successful and false if not -- you may want to be testing for that condition before proceeding with the rest of your code, because if the directory doesn't properly get created, all the rest of your code that relies on that directory existing is going to fail. Ultimately I think your browser is hanging upon submit because it is trying to access a function through PHP which there is no support for on Windows (chmod). Perform the function calls within a "Try/Catch" block to catch any exceptions that occur so that you can print them to screen or a log file if necessary:
$proceed = false;
try
{
// create directory
if (! is_dir(BACKUP_DIR)) {
$proceed = mkdir(BACKUP_DIR, 0777);
}
// or if it exists and has restricted file permissions, change them
elseif(fileperms(BACKUP_DIR)!=0777){
$proceed = chmod(BACKUP_DIR, 0777);
}
}
catch(Exception $e)
{
echo $e->message;
}
if($proceed == TRUE)
{
/*Proceed with your code*/
}
else
{
/*Gracefully fail*/
}
Good luck man, this is why I prefer Linux Boxes for web servers!
Cheers!
I'm trying to save a file in a folder other than the extensions folder. Right now I'm using:
var file = Components.classes["#mozilla.org/file/directory_service;1"].
getService(Components.interfaces.nsIProperties).
get("ProfD", Components.interfaces.nsIFile);
if( !file.exists() || !file.isDirectory() ) { // if it doesn't exist, create
file.create(Components.interfaces.nsIFile.DIRECTORY_TYPE, 0777);
}
this.f = file.path+"\\text.txt";
How can I change the file path so that it saves it somewhere else on the machine? Or is this not possible?
Thanks!
You can use different "special folder" keys too. For a list of some common ones, see:
https://developer.mozilla.org/en/Code_snippets/File_I%2F%2FO#Getting_special_files
You can also initialize a file with any absolute path. See:
https://developer.mozilla.org/en/Code_snippets/File_I%2F%2FO#Creating_an_.0ansIFile.0a_object_%28.22opening.22_files%29
I have a huge set of .vcproj files (~200) stored in different locations. I have a list of these files with full paths.
How can i automatically add them to the solution file(.sln) ?
UPD: I'm looking for existing tool/method.
Here's how I'd do it:
Create and save a blank solution to insert the vcproj files into (File->New Project->Other Project Types->Visual Studio Solutions->Blank Solution)
Create a VS macro which adds a project to a solution, saves the solution, and exits. Try the following:
Public Sub AddProjectAndExit(Optional ByVal vcprojPath As String = "")
If Not String.IsNullOrEmpty(vcProjPath) Then
DTE.ExecuteCommand("File.AddExistingProject", vcprojPath)
DTE.ExecuteCommand("File.SaveAll")
DTE.ExecuteCommand("File.Exit")
End If
End Sub
Create a batch script which executes this macro from the Visual Studio command prompt, iterating over each of your .vcproj files. The command for a single execution would be:
devenv.exe BlankSolution.sln /Command "Macros.MyMacros.Module1.AddProjectAndExit MyProject1.vcproj"
Hope that helps!
The .vcproj & .sln files are ascii format, so you could write a macro/script/program to run through your list of projects and insert the proper info into the .sln file. The only additional info you'll need to get about the projects is the project GUID, which can be found in the .vcproj file (assuming your build configurations are the same for each project).
Modify and existing vcwizard.
function CreateCustomProject(strProjectName, strProjectPath)
{
try
{
//This will add the default project to the new solution
prj = oTarget.AddFromTemplate(strProjTemplate, strProjectPath, strProjectNameWithExt);
//Create a loop here to loop through the project names
//you want to add to the new solution.
var prjItem = oTarget.AddFromFile("C:\\YourProjectPath\\YourProject.vcproj", false);
}
return prj;
}
catch(e)
{
throw e;
}
}