I (and my colleague) are having this problem with 32-bit applications on a 64-bit Windows 7 OS. We have also found the same problems when we invoke a 64-bit application and pass a path as described below as a parameter in cmd.exe.
Given the path "C:\dir1\dir2\file1.txt", we have some 32-bit applications that don't appear to be able to consistently resolve that path and find the file if there is a hidden file of a particular naming structure causing it to lose it's way.
For example, given the directory/file structure:
\dir1
\dir2
\file1.txt
\.dir2Blah
Of importance is that the "hidden" file's name starts with the same characters as those which indicate a directory at that same level of the hierarchy. What comes after that in the hidden file's name is irrelevant. It could be called ".dir2Whatever".
The problem is that more often than not (but not consistently always) some 32-bit applications we use can't find the file1.txt file. We're told it can't be found or it doesn't exist, etc. in the application. Using Process Monitor, we found the reason appears to be that while the path being asked for is C:\dir1\dir2\file1.txt, the path being evaluated by the the Windows system is C:\dir1\.dir2Blah\file1.txt.
We have found that some 32-bit applications appear to be able to work fine with those (what I would call) erroneous paths and successfully find the files in question but others do not.
As I said above, we have also found we can reproduce the problem with 64-bit applications if we try to open the file through a cmd.exe prompt; for example, "textpad.exe \dir1\dir2\file1.txt".
We've "googled" this problem for 2 days because we're completely stumped and cannot believe that no one else has ever encountered this if it's so "easy" to reproduce. My colleague and I are both able to cause the failure; not consistently, but file access will fail more than half the time when we set up the structure I described.
I've included a picture of Process Monitor showing this failure in two applications but succeeding in a third...here.
Can anyone tell me what is going on? First, why is it changing the path to use that hidden file rather than the directory name provided? And, more importantly, how can we make it stop ;-)?
Cheers,
jtm
Added later:
Here's the "dir /x" output for a directory where I'm having this problem.
24/05/2017 12:17 PM <DIR> .
24/05/2017 12:17 PM <DIR> ..
24/05/2017 12:17 PM 12 BLAHTS~1 .blahtst
23/05/2017 03:06 PM 104 JSHINT~1 .jshintrc
24/05/2017 12:16 PM <DIR> blah
24/05/2017 12:16 PM 0 blank.txt
24/05/2017 12:15 PM 6,624 INDEX~1.HTM index.html
24/05/2017 10:48 AM <DIR> js
It also indicates how we stumbled on the problem. I have an html file that is trying to load a JavaScript file under the /js directory, but there is also a .jshintrc file at the same level and my old Apache server can't find the files to serve them. If I remove the .jshintrc file, I can get around this, but this project isn't one I created and I'm leery of just removing things willy nilly.
Related
I'm not a front-end developer, but I need to get a sonarqube scan working with unit test coverage. All of this WAS working, but we had a big SonarQube version upgrade (6.x to 7.9.1), and it was broken for a while, and now I'm trying to get it working again.
As this used to work, what we have must be close, but there's some detail that isn't quite right.
When the build runs, it runs the unit tests and appears to generate coverage data, and the call to "sonar-scanner" sends the path to the lcov.info file. In the SonarQube project, it has a large number of "lines to cover", but with the same number of uncovered lines. I also note that it doesn't have a "Unit Tests" section in the overview.
In the build output, I see quite a few lines like this:
DEBUG: 'src/api/Api.spec.tsx' indexed as test with language 'ts'
But as noted above, the SonarQube project doesn't appear to think there are any unit tests.
As part of the build script, at the end of the tests run, I ran "ls -lt coverage" to see what was generated, and it showed this:
total 6264
-rw-r--r-- 1 81050 20059 1229978 Jan 4 19:12 clover.xml
-rw-r--r-- 1 81050 20059 720443 Jan 4 19:12 lcov.info
drwxr-xr-x 6 81050 20059 4096 Jan 4 19:12 lcov-report
-rw-r--r-- 1 81050 20059 4455341 Jan 4 19:12 coverage-final.json
I see references in this file to "Api.tsx" (and many others), but I don't see a reference to "Api.spec.tsx", but I have no idea whether I should expect any.
I've looked at the jest configuration in "package.json", but I don't see any obvious problems.
What else can I show here that might provide a clue?
Update:
Here is the resulting sonar-scanner command line, with some elisions:
sonar-scanner -Dsonar.typescript.node=/opt/app/bin/node -Dsonar.nodejs.executable=/opt/app/bin/node -Dsonar.host.url=http://... -Dsonar.login=... -Dsonar.password= -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info -Dsonar.typescript.lcov.reportPaths=coverage/lcov.info -Dsonar.branch.name= -Dsonar.language=js -Dsonar.projectKey=... -Dsonar.projectName=... '-Dsonar.exclusions=**/*.scss.d.ts, **/*.scss, **/*Props.ts, **/*State.ts, **/*index.ts' '-Dsonar.coverage.exclusions=**/*.spec.tsx, **/*.spec.ts, **/*.scss.d.ts, **/*.css.d.ts, **/*.scss' -Dsonar.projectVersion=1.0.0 '-Dsonar.sources=src/components/,src/api/,src/models/mappers/, src/utils/' '-Dsonar.lang.patterns.js=*/.ts,*/.tsx' -Dsonar.js.file.suffixes=.ts,.tsx -Dsonar.sourceEncoding=UTF-8 -Dsonar.tests=src '-Dsonar.test.inclusions=**/*.spec.tsx' -Dsonar.typescript.tslintconfigpath=tslint.json -Dsonar.log.level=DEBUG -Dsonar.verbose=true '-Dsonar.exec.maxBuffer=1024 * 1024'
I'd forgotten I'd asked this question. I had to go back to the code and history to see if I could remember what I did to fix it. I assume it would be what I discovered here:
https://community.sonarsource.com/t/sensor-sonarts-coverage-fails-to-match-path-with-symbolic-link/14601
In short, if file paths in the generated files include symbolic link entries, there was a bug in SonarTS that made it fail to follow symbolic links. What I did to fix this particular problem was examine my generated files to understand the pattern of what symbolic links were being utilized, and I wrote a script to post-process the lcov.info and test-report.xml file to replace paths to symbolic links with the absolute path to the non-symlinked file.
I went downloaded the Apktools from the website and got 2 files: Apktool.txt and Apktool_2.2.2. I renamed the Apktool_2.2.2 to Apktools.jar per the instructions. I then went to terminal and this was what I did:
Last login: Fri Mar 17 12:08:55 on ttys000
Roberts-MBP:~ Robert$ cd documents
Roberts-MBP:documents Robert$ cd metronomeapp/apktool
Roberts-MBP:apktool Robert$ **java -jar apktool.jar**
Apktool v2.2.2 - a tool for reengineering Android apk files
with smali v2.1.3 and baksmali v2.1.3
Copyright 2014 Ryszard Wiśniewski <brut.alll#gmail.com>
Updated by Connor Tumbleson <connor.tumbleson#gmail.com>
usage: apktool
-advance,--advanced prints advance information.
-version,--version prints the version then exits
usage: apktool if|install-framework [options] <framework.apk>
-p,--frame-path <dir> Stores framework files into <dir>.
-t,--tag <tag> Tag frameworks using <tag>.
usage: apktool d[ecode] [options] <file_apk>
-f,--force Force delete destination directory.
-o,--output <dir> The name of folder that gets written. Default is apk.out
-p,--frame-path <dir> Uses framework files located in <dir>.
-r,--no-res Do not decode resources.
-s,--no-src Do not decode sources.
-t,--frame-tag <tag> Uses framework files tagged by <tag>.
usage: apktool b[uild] [options] <app_path>
-f,--force-all Skip changes detection and build all files.
-o,--output <dir> The name of apk that gets written. Default is dist/name.apk
-p,--frame-path <dir> Uses framework files located in <dir>.
For additional info, see: http://ibotpeaches.github.io/Apktool/
For smali/baksmali info, see: https://github.com/JesusFreke/smali
Roberts-MBP:apktool Robert$ **./apktool d metronome.apk**
-bash: ./apktool: No such file or directory
Roberts-MBP:apktool Robert$ **apktool d metronome.apk**
-bash: apktool: command not found
Roberts-MBP:apktool Robert$
You can see in the bold what I entered. On the 2nd and 3rd bold statements, I did it both ways because I found info that one of them works on windows and one on mac and since the mac one didn't work I wanted to try the windows one to see what it would say. Both the files are in the same directory with the apk file (metronome.apk) Does anyone know why this isn't working and what I can do to resolve it?
Thanks.
Robert
Try java -jar apktool.jar d metronome.apk
To elaborate, apktool.jar is not a command itself. It's a java Jar file that can be executed by the Java runtime.
In Windows according to
docs
I set P4SSLDIR:
set P4SSLDIR=E:\Programs\perforce\P4SSLDIR\
Trying to generate certificate and private key gives error:
C:\programs>p4d -Gc
Perforce server error:
P4SSLDIR not defined or does not reference a valid directory.
How to overcome this to generate priv key and certificate?
p4d can not understand last backslash in path.
Examples in docs for *nix.
Fix of the problem:
set P4SSLDIR=E:\Programs\perforce\P4SSLDIR
Incorrect:
set P4SSLDIR=E:\Programs\perforce\P4SSLDIR\
I couldn't reproduce this with a simple experiment (I used Perforce 2013.3, which is the version I happen to have):
C:\Users\Bryan\perforce\my-test-server>mkdir P4SSLDIR
C:\Users\Bryan\perforce\my-test-server>set P4SSLDIR=C:\Users\Bryan\perforce\my-test-server\P4SSLDIR
C:\Users\Bryan\perforce\my-test-server>p4d -Gc
C:\Users\Bryan\perforce\my-test-server>dir P4SSLDIR
Volume in drive C is OS
Volume Serial Number is 6602-B38E
Directory of C:\Users\Bryan\perforce\my-test-server\P4SSLDIR
05/24/2015 09:36 AM <DIR> .
05/24/2015 09:36 AM <DIR> ..
05/24/2015 09:36 AM 1,172 certificate.txt
05/24/2015 09:36 AM 1,704 privatekey.txt
You might need to contact Perforce Technical Support for assistance, as it might be something very specific to what you're doing.
I had some iOS projects in my macbook,one day I copied them to my pc which is based on windows system, then some day I copied them back to my macbook and I found the projects can not run.
I Opened one of the projects with Xcode, it says "builde successfully",but the app can not be deployed on the iPhone Simulator even if the Simulator is running!?!?!?! Then I check the files using "ls -l" command and found that the difference between normal Xcode project files and the new created Xcode project files is just a symbol.
files with problem:
drwx------+ 49 dingvimer staff 1.6K
normal file：
drwx------# 60 dingvimer staff 2.0K
How can I change that '+' symbol to '#' and get the project run normally?
I will appreciate your kindness of helping me to figure it out (^-^).
You can use ls -l# to see extended attributes. It will show you something like:
drwxr-xr-x# 5 cody staff 170 Mar 30 08:46 test.xcodeproj
LastUpgradeCheck 4
LastUpgradeCheck - is the name of attribute (sometimes there can be something like com.apple.blablabla) and 4 - is the value.
Use xattr command to set/delete extended attributes. See man xattr (its quite short and there are some examples).
Note, that you'll probably need to fix whole project directory.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
PROBLEM IS SOLVED!
Follow the instructions Dons posted here
Open your environment variables (My Computer -> Properties (in the context menu) -> Advanced)
Add to or make a new environment variable C_INCLUDE_PATH so it points to MPI's include directory. In my case, /c/program files/mpich2/include.
Add to or make a new environment variable LIBRARY_PATH so it points to MPI's lib directory. In my case, /c/program files/mpich2/lib
Hide libmpi.a somehow. If need be, you can fix this later. It is a hack but you cannot build haskell-mpi without doing it because ld will fail. I renamed it to _libmpi.a
Now haskell-mpi should build on windows. Anticipating more trouble down the line, but it built, and it solved my problem.
I am wanting to use haskell-mpi on a lab machine at one of my university labs to do my final project for my parallel computing class, but I am running into trouble trying to get haskell-mpi to build against MPICH2.
haskell-mpi is pretty much completely undocumented, and digging through their git repository has helped me program some example programs on it but has done nothing to help me set it up on Windows. On my personal linux system, I had no trouble setting up and running haskell-mpi against MPICH2.
The problem is probably in one of cabal, the way MPICH2 is installed, or with haskell-mpi's cabal configuration, hence the choice of tags.
I am open to experimenting here for the sake of troubleshooting, and adding more information as needed, but eventually I will no longer have access to these machines.
I have administrator rights in the lab where I will be running this, so if the problem is with the MPICH2 installation itself, I could indeed reinstall it.
cabal fails as follows when I try to install haskell-mpi:
Resolving dependencies...
Configuring haskell-mpi-1.0.0...
cabal: Missing dependency on a foreign library:
* Missing C library: mpi
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Error: some packages failed to install:
haskell-mpi-1.0.0 failed during the configure step. The exception was:
ExitFailure 1
Here are what I tried giving for --extra-lib-dirs and --extra-include-dirs:
--extra-lib-dirs="C:\Program Files\MPICH2\lib"
--extra-include-dirs="C:\Program Files\MPICH2\include"
I've tried reordering where I put those flags, escaping the backlashes, using the short path PROGRA~1 and various permutations of these. So I don't think this is going to help. I need to know what the mpi dependency actually means and figure out how I will satisfy it so that this library can actually build. Here is what lives in the two aforementioned folders at this moment:
Libs:
Volume in drive C has no label.
Volume Serial Number is 5406-5C5C
Directory of C:\Program Files\MPICH2\lib
04/22/2011 01:20 PM <DIR> .
04/22/2011 01:20 PM <DIR> ..
01/31/2011 03:59 PM 515,704 cxx.lib
01/31/2011 04:23 PM 137,434 fmpich2.lib
01/31/2011 04:25 PM 410,982 fmpich2g.lib
01/31/2011 04:29 PM 162,690 fmpich2s.lib
01/31/2011 04:53 PM 0 libfmpich2g.a
01/31/2011 04:53 PM 0 libmpi.a
01/31/2011 04:53 PM 215,528 libmpicxx.a
01/31/2011 04:16 PM 10,618 mpe.lib
01/31/2011 04:46 PM 135,434 mpi.lib
9 File(s) 1,588,390 bytes
2 Dir(s) 221,505,835,008 bytes free
Include:
Volume in drive C has no label.
Volume Serial Number is 5406-5C5C
Directory of C:\Program Files\MPICH2\include
02/01/2011 05:38 PM <DIR> .
02/01/2011 05:38 PM <DIR> ..
11/17/2009 09:46 PM 4,857 clog_commset.h
11/02/2007 05:50 PM 696 clog_const.h
01/31/2011 03:50 PM 731 clog_inttypes.h
11/17/2009 09:46 PM 1,353 clog_uuid.h
10/21/2010 01:20 PM 355 mpe.h
11/17/2009 09:46 PM 11,102 mpe_log.h
11/02/2007 05:50 PM 1,833 mpe_logf.h
11/17/2009 09:46 PM 1,322 mpe_misc.h
01/31/2011 03:50 PM 57,128 mpi.h
01/31/2011 04:23 PM 3,251 mpi.mod
01/31/2011 03:50 PM 97,267 mpicxx.h
01/31/2011 03:51 PM 19,051 mpif.h
01/31/2011 03:50 PM 16,765 mpio.h
01/31/2011 04:23 PM 13,668 mpi_base.mod
01/31/2011 04:23 PM 30,866 mpi_constants.mod
01/31/2011 04:23 PM 7,802 mpi_sizeofs.mod
16 File(s) 268,047 bytes
2 Dir(s) 221,505,830,912 bytes free
Is there anything here that might be recognizably missing?
I am quite stumped at this point. Just about any suggestion would be helpful.
Sincerely, Barend.
PS: This should probably be tagged "haskell-mpi", but I'm not allowed to make new tags. I guess nobody else is really using it yet.
EDIT: Following Dons' suggestion,
I installed MingGW and MSYS. After running mingw-get update, I used mingw32-get to retrieve libtools, mingw32-utils, and mingw32-binutils. I set the following environment variables for the whole system using the Windows configuration GUI:
LIBRARY_PATH="C:\Program Files\MPICH2\lib"
C_INCLUDE_PATH="C:\Program Files\MPICH2\include"
echo $LIBRARY_PATH and echo %LIBRARY_PATH% now both work as expected, no surprises there. The environment variables are set. Making progress.
cabal install haskell-mpi still produces the same output it did before.
Played with ld for a long time, huge red herring...
I had to hide libmpi.a from ld to get it to work, but haskell-mpi now builds!
Putting step by step details at the top.
I need to know what the mpi dependency actually means
The line extra-libraries: mpi means that Cabal will add -lmpi to the ld linker options. In addition, tools that process headers will search in the include paths.
So, how do we help GHC and binutils find that library?
According to the wiki, assuming you have mingw or msys,
If you need to link to C-software, define an environment variable C_INCLUDE_PATH that lists the directories where the header files can be found. For linking the libraries you need to define an environment variable LIBRARY_PATH as well, listing the directories where .a and .lib files can be found.
So try setting the paths to include the path to the headers and libraries.