I try to commit a folder hierarchy into out Mercurial repository, which contains files, whiches absolute path length exceeds 255 characters (Windows max. path length).
For these files I receive an error message saying
The system cannot find the path specified
We use TortoiseHG and an Eclipse plugin for Mercurial, both don't work.
Has anybody found a solution for this?
(I do not want to change the repository's location on my HD)
There exists an extension which is aimed at solving this exact problem. It is: https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension
It uses \\?\ style names to transparently handle long files.
I'm the author, let me know if it works for you.
I've just installed Aaron Cohen' extension, as he suggested.
And it perfectly works with my TortoiseHG 2.6.1 ! Thanks, Aaron!
Though, I'd like to add a detailed guide here, because I cannot find one...
(At least here's what I did on my Win7 x64 - I'm not sure this is the shortest way possible)
1. Download Mercurial-py
Note the Python version required
I've downloaded "Mercurial-2.4.2 (64-bit py2.7)"
2. Download Python
Make sure you're downloading compatible version.
I used "Windows X86-64 MSI Installer (2.7.3)" link
3. Install Python
I've installed it to "D:\Python27"
4. Download pywin32
It's required by the Win32LongFileNamesExtension.
Note the Python version number in pywin32's filename.
I used "pywin32-218.win32-py2.7.exe"
5. Install pywin32
Make sure installer detected correct Python installation
In my case, it's installed in "d:\Python27\Lib\site-packages\pywin32_system32\"
6. Install Mercurial
Make sure installer detected correct Python installation
In my case, it's installed in "d:\Python27\Lib\site-packages\mercurial\"
7. Set PYTHONPATH enviroment variable
setx PYTHONPATH d:\Python27\Lib\site-packages\win32lfn\src;d:\Python27\Lib\site-packages\mercurial\
Use this cli command, or do the same using some other method
Of course, you should adapt paths to your needs
Restart your cli after this, to make sure env. variable is now properly set
8. Download win32lfn
Check for availible downloads on the project's repository page
If there's still nothing, just clone a repository from https://bitbucket.org/remleduff/win32lfn to "d:\Python27\Lib\site-packages\win32lfn\"
Now "win32lfn.pyc" should be in "d:\Python27\Lib\site-packages\win32lfn\src\"
9. Do interanal win32lfn tests
cd /D D:\Python27
python d:\Python27\Lib\site-packages\win32lfn\tests\testwin32lfn.py
10. Create a backup of your repository.
For me, everything went just fune, but you never know....
11. Add win32lfn to hgrc
[extensions]
win32lfn = d:\Python27\Lib\site-packages\win32lfn\src\win32lfn.py
you can find "hgrc" in your ".hg" folder, inside your repository
12. Test it!
The quick and dirty solution is to map a network drive.
For the path c:\some long path\project folder
Map \\localhost\c$\some long path\ to drive Z:\
cd z:\project folder
hg push
We are using this successfully as an interim solution, before migrating to shorter paths.
The mercurial plugins above look good but unfortunately there are numerous non-mercurial bugs related to path greater than 255 characters. For example the VS2010 failure at exactly 259 characters is a real corker!
http://support.microsoft.com/kb/2516078
See https://www.mercurial-scm.org/wiki/Win32LongFileNamesExtension (Aaron pointed to it via the mercurial-devel mailing list).
Another workaround without changing the path to the repo could be to create a second path to it by means of directory junction points. It may work because the reparsing is done at a very low level by the file system driver (or rather some installed filter), so the full (Unicode) path is known by that time and the expansion to beyond 260 characters should work fine. Give it a try. You can use the tool mklink on Windows Vista or 7 and junction.exe from Sysinternals on Windows 2000 or later. For mklink make sure to create a junction point. I'm not sure the reparsing mechanism works the same for directory symlinks (although I faintly remember that it should).
If you don't have a Unicode version of the program available, the limit is 260 characters (including drive letter part). There is nothing to get around it.
However, all ANSI functions are implemented by means of their Unicode counterpart and therefore you may get lucky by providing the full path prepended with \\?\. This may work, but likely won't because the program itself didn't consider anything beyond MAX_PATH (= 260). Ask the author to compile a Unicode version and use the prefix I mentioned. This will fix the issue.
This is a limit of the Win32 subsystem. The absolute path length limit is approximately 32,767 characters. Approximately because the object manager of Windows may expand it (symlinks in the object namespace and the likes).
Windows 10 system running the mercurial 4.4.1 client
Aaron Cohen extension will work I did need make a small one small tweak
based on a comment from mhaecki on this thread: https://bitbucket.org/remleduff/win32lfn/issues/13/not-compatible-with-version-431
in the win32lfn.py file I changed:
from mercurial import util, osutil,cmdutil
from mercurial.i18n import _
to:
from mercurial import util, cmdutil
from mercurial.cext import osutil
from mercurial.i18n import _
Related
Does anyone know how to delete those past working directories in Octave GUI? They are very annoying and useless.
I see from your image that you are on windows.
I don't know the equivalent directory on windows, but on linux, this information seems to be stored under ~/.config/octave/octave-gui.ini, in a section called current_directory_list which you can edit and clear of all unwanted entries.
See if you can find the equivalent folder where this octave-gui.ini file is stored on windows; it may be in an AppData/Local directory, or in the octave installation folder itself...
PS: In the same directory I also had a qt_settings file which seems to mirror some of this information, but I think this may have been from an older octave installation.
In addition to deleting the file path from octave-gui.ini, try removing the path from .octaverc file as well. This will remove the warning you see at launch if the path no longer exists.
Running the Config Wizard via the start menu (Windows 7) simply fails. Running it from the command prompt shows the infamous
'C:\Program' is not recognized as an internal or external command, operable program or batch file
I know this is due to the space in "Program Files" (dir C:\pro* /x doesn't show C:\Progra~1).
The solution I've found for this is to replace C:\Program Files\... with "C:\Program Files\...".
My question is this:
Since the WebLogic config wizard runs from config.cmd, which is loaded with variables for path names, do I have to update Windows system environment variable PATH and put quotes around all path names that have a space (since I don't know what WebLogic is looking for)?
Update:
I tried this and received Files was unexpected at this time. Which made me think I was off with the quotes, but they are paired properly around every path with C:\Program Files. A search on this error resulted with this advice...basically the double quotes are the cause.
If the lack of quotes causes the first problem, and the presence of quotes causes the second problem, what to do? It's a loop...
I installed another JDK in a location with no spaces (still got the error because I didn't change any environment variables because work site will change them back, breaking things).
The install docs in chapter 4 say:
To begin domain configuration, navigate to the
ORACLE_HOME/oracle_common/common/bin directory and start the
Configuration Wizard.
On UNIX operating systems:
./config.sh
On Microsoft Windows operating systems:
.\config.cmd
Which implied at a command prompt (to me anyways). I was reading another site for help and the guy said to update config.cmd to point it to new JDK location instead of JAVA_HOME.
Instead of right clicking on config.cmd to edit it I double clicked it and lo and behold...this nice domain creator GUI opened up where I could specify which JDK to use. Done! No errors...
If that little tidbit were in the docs it would've save me a lot of time and frustration. And no, I'm not a server admin type, just a dev who needed a local web server for testing purposes.
I hope this helps someone.
I am trying to install RMySQL on my mac (mavericks) and it errors out when I try to build it from source, saying:
Configuration error: could not find the MySQL installation include
and/or library directories. Manually specify the location of the
MySQL libraries and the header files and re-run R CMD INSTALL.
INSTRUCTIONS:
Define and export the 2 shell variables PKG_CPPFLAGS and PKG_LIBS to include the directory for header files (*.h) and
libraries, for example (using Bourne shell syntax):
export PKG_CPPFLAGS="-I"
export PKG_LIBS="-L -lmysqlclient"
Re-run the R INSTALL command:
R CMD INSTALL RMySQL_.tar.gz
I tried to follow the instructions by entering:
export PKG_CPPFLAGS="-I/usr/local/mysql/include" export
PKG_LIBS="-L/usr/local/mysql/lib -lmysqlclient"
but when I re-run RMySQL it still doesn't work. Moreover, if I type
$PKG_LIBS
to see what that variable holds, I get
-bash: -L/usr/local/mysql/lib: No such file or directory'
I know that /usr/local/mysql/lib exists and it does contain a mySQL header. Am I misunderstanding the instructions?
I'm asking here only after a lot of effort to find solutions and/or work arounds. Sucks being a noob sometimes.
I am going to assume you're trying to get RmySQL to run on R 3.1.0 on Mavericks? Rather than worry about exporting variables etc, here is a simple clean solution for you that should avoid the headaches.
The RMySQL install link Pascal provided above really is your solution. You're probably just stumbling on syntax, or getting things to work from the terminal.
Even if you're a "noob", you should be able to get this working. I'll try to offer a "dummy's guide" walk through here, as I bet there are many others who have this problem too, even after trying to read the RMySQL installation readme.
I would bet with very high confidence the problem is just that you aren't specifying correctly the locations of the library and header folders for compiling. Read the errors carefully when you try to compile... the errors will probably tell you a file/header is missing, or some .so file (shared object) is missing.
One simple way compile RMySQL from source on R 3.1.0, mavericks is as follows (this does not require you to set any environmental variables, no editing of the Renviron file, etc):
Does MySQL work by itself? i.e. Can you open/run it no problems? If not, fix that first.
Find the precise location of your mysql installation. For me, on Mavericks, I see mysql installed at /usr/local/mysql-5.6.17-osx10.7-x86_64 (your version number may be different). There is also another folder /usr/local/mysql which is an alias to /usr/local/mysql-5.6.17-osx10.7-x86_64 (/usr/local/mysql finds the current version of mysql you are using, if multiple mysql file folders exist, I think). In this directory, I see two sub directories (among many) called "include" and "lib". Take a look; "include" will contain header files (include as in #include , etc, in simple C++ programs). The "lib" folder contains compiled source code of the mysql library.
An easy way to compile and install RMySQL which doesn't exactly follow the suggested way to do it in the installation guide is this. Note that this is doing the same thing as in the installation guide, just a little easier as it's one command line from the terminal, once you know where your mysql install folder is. Go to the terminal, and type the following exactly, with one space between each chunk (with your mysql folder name adjusted appropriately for the version number):
PKG_CPPFLAGS="-I/usr/local/mysql/include/" PKG_LIBS="-L/usr/local/mysql/lib/ -lmysqlclient" R CMD INSTALL RMySQL_0.9-3.tar.gz
OR (the same thing, just more typing)
PKG_CPPFLAGS="-I/usr/local/mysql-5.6.17-osx10.7-x86_64/include/" PKG_LIBS="-L/usr/local/mysql-5.6.17-osx10.7-x86_64/lib/ -lmysqlclient" R CMD INSTALL RMySQL_0.9-3.tar.gz
Note for dummies: Make sure when you run this command, that you are doing it from the terminal in the directory that contains the RMySQL_0.9-3.tar.gz file (or whatever the name of your folder is that contains the RMySQL source code)
and RMySQL compiles!
Don't be afraid about trying to compile source code -- it's not just for 'compiled language programmers' or 'computer science graduates'. Most of the time when compiling fails it's just because files are "missing" (there is no corruption on the source code) -- the user hasn't properly specified the locations of the header and libraries (shared objects). Now pull your big boy/girl panties up and just do it .... it's easy.
Notes for people clueless about compiling source code for packages in R:
a) pay special attention to the spacing in the above, otherwise it may not work. Do not have any spaces between the = and the variable/file names (e.g. don't try and have in the above PKG_CPPFLAGS ="-I/usr/local/mysql/include/" as it won't work)
b) When compiling, you want to specify the locations of the header files and the library files and this is what the "-I/ .... " and "-L/ ...." are doing. The -I directory specifies the location of the header files, and the -L the location of the library files. The library files also require the -l[name of library] extension (the -l is short for -lib in the library object names).
c) Note that in the directory /usr/local/mysql-5.6.17-osx10.7-x86_64/lib/ I do not see a file called "lmysqlclient", or even "libmysqlclient", but I do see files named (among others) "libmysqlclient.a" and "libmysqlclient.18.dylib". So don't worry about your MySQL installation not being correct if you don't see a file just called "libmysqlclient" in the lib folder.
I installed mercurial 1.5.1 on win xp but the files listed in hg help config, were not created.
Namely:
%USERPROFILE%.hgrc (is that a valid windows file name?)
%USERPROFILE%\Mercurial.ini
\Mercurial\Mercurial.ini
C:\Mercurial\Mercurial.ini (no such directory altogether)
%HOME%.hgrc (what is this directory)
%HOME%\Mercurial.ini
HKEY_LOCAL_MACHINE\SOFTWARE\Mercurial (no registry created)
.hg\hgrc (i had to create this file manually to solve my problem)
They're not supposed to be automatically created. They're places you can put configuration information depending on what scope you want it to have:
C:\Mercurial\Mercurial.ini - If you choose to create this whatever you put in it affects all users on the systme
%USERPROFILE%\Mercurial.ini - If you choose to create this whatever you put in it affects only you, but in every repo with with you interact
((repository root))\.hg\hgrc - If you choose to create this whatever you put in it affects only the repository in which you placed it
So, it's all about scope. Something like enabling an extension might be best done system global in C:\Mercurial. Something like setting your username is probably best done only for you, in your %USERPROFILE%\Mercurial.ini. Saving a password for a repository (if done at all) probably goes inside that repos .hg/hgrc file.
As explained by Daniel in the comments, %USERPROFILE% is the expansion of an environment variable. That's necessary because your home directory location differs depending on what version of windows you have, how your administrator configured it, and your name.
AFAIK, the files are not created by default. For storing the login IDs, it's usually a good idea to do what you did, especially if you have a different username for each project you work on.
Otherwise, you could create a Mercurial.ini file under C:\Documents and Settings\<user name>\ (as you are using Windows XP) or under C:\Users\<user name> (if you're using Windows Vista or Windows 7)
If I run Inno Setup compiler from a command line/batch file it creates an exe with the version information in the file name.
However, when I run from hudson (same command line) I don't get the version information.
Perhaps I am missing something.
Is this a known issue?
This is the way I am doing it in the iss script file.
#define FileVerStr GetFileVersion(SrcApp)
EDIT:
The env vars are all set for all users - not just my login - so the service has access to everything that the command line build does.
EDIT: See my answer for a resolution of this.
Like "tim" has said, then relative paths doesn't work as expected for defines.
#define MyAppVer GetFileVersion(SourcePath + "\..\Build\Release\MyExeName.exe")
#if MyAppVer == ""
#error MyAppVer - Version information not found!
#endif
By prefixing with SourcePath then the relative path will start from the path where the InnoSetup-script is located.
You are likely running Hudson on Windows given the technology mentioned.
When there is a discrepancy between what happens on the command line and what Hudson does, it is often because Hudson is running as a service on Windows. This means it is running as the service user, which is distinct from your login account.
I would look for an environment variable that you have defined in your user profile that may enable this behavior, that is not being set for the service user.
I am not exactly sure how to describe how I "fixed" this/worked around it.
It seems the GetFileVersion() method does not use the same base path as the other part of the Inno functionality that determines where the source files/installable files are.
The SAME relative paths used for:
// this is for determining what files get put into the install image
[Files]
Source: ..\Build\ForRelease\MyExeName.exe; DestDir: {app}
and
#define SrcApp "..\Build\ForRelease\MyExename.exe"
#define FileVerStr GetFileVersion(SrcApp)
apparently do not use the same mechanism to resolve the file name/path. So what i did to work around this was to copy the exe file that contains the version info to two additional different locations (aside from ..\Build\ForRelease) - one where hudson starts the processes and also to the path where the inoo script is. (I am too lazy to figure out which one is the one that makes it all work.
Again, this works fine from my batch file but not from hudson. It is essentially a strange interaction with how Inno works I guess.