running the solvers in a path with space in the naming #Windows #WSL
I'm here again with some Windows WSL issues :(
I am doing lots of simulations and I have to use Microsoft OneDrive for Business to sync them across computers. I'm running these simulations in WSL but I guess it wouldn't make a difference if I do that in a Docker container or Cygwin. The issue is that OneDrive for business, at least in my university, has an absurd naming where there are multiple spaces in the local folder naming. For example OneDrive saves files in a folder named OneDrive - University of Bar.
Now whenever I try to run a code inside this folder I get the error:
Build : v1806
Arch : "LSB;label=32;scalar=64"
Exec : sonicFoam
Date : Sep 16 2018
Time : 23:30:13
Host : "DESKTOP-4LRIVB8"
PID : 510
fileName::stripInvalid() called for invalid fileName /mnt/c/Users/buzz/OneDrive-UniversityofBar/Projects/…
For debug level (= 2) > 1 this is considered fatal
Aborted (core dumped)
I have tried for almost one week to solve this issue and it has wasted so much of my time already. You may see my struggle here. This actually one of the reasons I am using WSL instead of Docker now. I have tried creating a link by:
ln -s "~/some/path/OneDrive - University of Bar" ~/linkFileHowever when I run the solver I get the same error!
I would really appreciate if you could help me solve this problem.
## Reattaching the author to the issue ticket: @foadsf ##
Activity
This is actually a very common issue and there is even a wiki entry for it. This issue could be probably reduced if OpenFOAM internal code would use a relative address instead of absolute. or in the case where there are spaces in the namin just put quotations around it.
By Foad on 2018-09-18T11:43:51 (imported from GitLab project)
## Reattaching the author to the issue ticket: @foadsf ##
I guess I have the same problem here. Every time I open the Ubuntu, it shows "bash: eval: line xx: syntax error near unexpected token '(' and then followed by a lengthy file paths...
I guess it does not allow symbols either, like the (, ).
By Zilong on 2018-10-01T22:46:23 (imported from GitLab project)
-
## Reattaching the author to the issue ticket: @Enginear ##
assigned to @mark
-
Need to take a deeper dig to see what would break, where. Some first thoughts...
Using a relative path for the case could be reasonable. We'd need an initial chdir() whenever a
-case ...option is triggered (unless running as distributed?). Since argList is only ever called once per application (also sets up and takes down parallel), there are no expected conflicts or confusion there. In parallel, it would probably need to be left with the case and not the processor-case directory.I think the problem starts after that. The OpenFOAM
fileNamecan't currently contain any spaces. The reason being that it should essentially be a^/?word? (/word)*$composition. This means that thefileName::name()method returns awordto the last part of the path. Allow spaces here and the parsing of dictionary input largely breaks. The only immediate workaround there might be to have word input/output handle spaces. Eg,type 'word with space';Does this make things robuster and cleaner? Or uglier and more fragile?
Richard Smith from Symscape has implemented in his ports of OpenFOAM to Windows, for several years now, the allowance of having spaces in folder and file names. Everyone who has inherited his patches, has been using this feature on Windows.
I vaguely remember that there were at least two changes needed in the code to allow this and the only one I can remember right now is in
inline bool Foam::fileName::valid(char c): https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/OpenFOAM/primitives/strings/fileName/fileNameI.H#L108 - where the line for!isspace(c) &&is commented out.Beyond this, on the Windows command line and Bash/shell on Windows, the use of names with spaces is usually handled by using quotes to ensure that the sentence is cohesive... which leads to a bit of a nightmare when having to support scripts that can handle spaces in their names. Most of the situations are more easily solved if we rely on the short 8.3 alternative on Windows with folder/file naming, although it's just a workaround.
As for the problem with the spaces and parenthesis on the WSL within Windows when sourcing
bashrc, the (partial) solution has already been indicated in the report #1007 (closed).By Bruno Santos on 2018-10-15T10:56:41 (imported from GitLab project)
-
## Reattaching the author to the issue ticket: @wyldckat ##
-
I'm still a bit hesitant to let whitespace creep into
fileNameandwordas valid characters, for reasons outlined above. If we allow it infileName, we'd also need to have it inwordand also need to deal with them on input and output. Unless of course we decided to be inconsistent and only allow them in the path part offileName?As an alternative, I've now added in support for using the logical value for
cwd(), but noticed that I only tagged it as #1007 (closed) (Please read the comments in commit b705427298).I think that this in not a bad way to ship around the problem. In fact, I'd be quite tempted to make the use of logical
cwd()the new default.Please test and let me know what you think.
/mark
mentioned in issue #1030 (closed)
@mark thanks for your response at StackOverflow.I am the one who asked the question there. In your last comment, I think you said you have a fix. can you explain the procedure of how to fix it?
By Daniel Dolatabadi on 2018-10-16T07:27:37 (imported from GitLab project)
-
## Reattaching the author to the issue ticket: @typerhack ##
-
Hi @typerhack , glad you got back to us. Unfortunately my responses on StackOverflow (user10142377 - from my phone) are getting deleted as being non-relevant, or whatever. I don't really necessarily understand why.
As I posted there:
The main culprit is the IFS handling in the foamCleanPath script. The first IFS (Line 184 in the 1806 version) stays as it is (with whitespace splitting on the filter arguments). The second IFS (Line 206) should be modified to not use whitespace for its splitting. Finally, the restoring of the old IFS can probably move below the for loop.
If you have enough reputation, maybe you could repost my (deleted) responses, with the hope that someone else benefits too.
@mark Thankyou for your time and efforts, I'll do my best to repost your responses. actually, your last response is still available. I don't get how can I fix this issue. Should I replace the codes with your suggestion or a patch would be available? though I know my way around, I am not an advanced user of bash. so it would be really helpful if you could give me a step by step manual or a file to replace. I am sorry if I am asking too much. I really don't know how this works in this community.
By Daniel Dolatabadi on 2018-10-16T11:38:39 (imported from GitLab project)
-
No worries, if you can just exchange the file contents of foamCleanPath with these https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/bin/foamCleanPath it should be okay. Of course, make a backup copy of that file before you replace things, and don't forget to check that you don't have some windows line-endings creeping in (depending on how you download it).
@mark worked like a charm on my pc. The problem is solved. thank you for your generous help and time. I'll update the StackOverFlow post. I tested it on my laptop I got a new error : "blockmesh: command not found". I'm trying to solve this now.
By Daniel Dolatabadi on 2018-10-16T20:45:54 (imported from GitLab project)
Thank you it was just Like you said. The program is working. I copied the cavity folder into the home and tested it and everything worked. I just want to report that when I copied cavity folder into this address:
C:\My Files\OpenFoam\Tutorial\cavityThe blockMesh command exited with fatal error:/*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1806 | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Build : v1806 Arch : "LSB;label=32;scalar=64" Exec : blockMesh Date : Oct 17 2018 Time : 13:01:44 Host : "DESKTOP-I24KEL4" PID : 565 fileName::stripInvalid() called for invalid fileName /mnt/c/MyFiles/OpenFoam/Tutorial/cavity For debug level (= 2) > 1 this is considered fatal Aborted (core dumped)I think this also happens because of a space character. The Correct address is /'My Files'/ or /My\ Files/, but in error, it is MyFiles.
By Daniel Dolatabadi on 2018-10-17T09:38:43 (imported from GitLab project)
-
This is what @foadsf reported at the beginning of this particular issue and this was the reason for the changes in commit b7054272. The explanation there is fairly reasonable (I think), but maybe helps to explain why this arises and why we don't fix it in a particular way.
The really quick way to avoid it is to override the checking and stripping of spaces from the fileName. This can be changed in the OpenFOAM etc/controlDict file. There is a section of
DebugSwitches, where you can change the value. Eg,DebugSwitches { ... fileName 0; // was 2, could also use 1 for messages only. }This should get you running. But it does introduce a possible internal inconsistency when your case name itself contains spaces.
Edited by Mark OLESEN
