The problem that I'm having is frankly baffling. I was doing some python coding, come back the next day, and without changing anything, the code stopped working, giving a FileNotFoundError. I've whittled it down to a laughably simple minimum code to produce the error.
f = open('positions.tsv','w')
Which produces the error
Traceback (most recent call last):
File "c:/Users/mrhel/Documents/GitHub/gas-collisions/test.py", line 1, in <module>
f = open('positions.tsv','w')
FileNotFoundError: [Errno 2] No such file or directory: 'positions.tsv'
I have been scouring the internet for hours for a solution but everything I come across is someone trying to create a file in a folder that doesn't exist or forgetting to set the mode to 'w'. I copied the exact code that this is happening with onto a Linux machine and it runs just fine, it is specifically not working on my Windows 10 machine.
I have tried rebooting the computer, which doesn't work either. Why would this simple line of code not work specifically on Windows?
Edit:
How I run the code is either python test.py or C:/Users/mrhel/AppData/Local/Microsoft/WindowsApps/python3.8.exe c:/Users/mrhel/Documents/GitHub/gas-collisions/test.py
In any case, the expected behavior according to the open() documentation
is that positions.tsv should be created upon calling this function with the 'w' mode.
When I do create the file in advance, I get an error when I try to write to it.
f = open('positions.tsv','w')
f.write('testing')
f.close()
Error:
OSError: [Errno 9] Bad file descriptor
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "c:/Users/mrhel/Documents/GitHub/gas-collisions/test.py", line 3, in <module>
f.close()
OSError: [Errno 9] Bad file descriptor
Edit 2:
I tried creating a file and reading it, and that works as expected. It's specifically writing that isn't working
Edit 3:
So since it runs in another folder, I decided to check for write permissions, and this is what I got. When I check properties of the folder with windows, all users have allow ticked.
>>> os.access('my_folder', os.W_OK)
False
This is clearly a permissions issue, but I'm not sure how to rectify it.
This turned out to be a result of "Controlled Folder Access" in Windows Defender Ransomware Protection. Turning off this feature allows it to function as expected. It's not clear how Ransomware Protection decided that my code is not to be trusted, but for posterity's sake, that is how this was fixed.
Related
After a bit over 8 years of using Python I've run today into issue with Python 3.8: it executed code that I commented out.
I was able to interrupt it as it was going through code path that should have been blocked by the comment to get this screenshot:
As the function names indicate, the operation in question is somewhat time-consuming to rollback and I would love to know what happened to avoid dealing with that in the future.
My current best explanation is that since the code is run on a remote machine for whatever reason the commenting out did not go through when the code started, but did for the stack trace.
Does anyone had a similar experience or have an idea of what might have happened?
I confirmed my hypothesis from the comments, with a file like:
import time
def dont_run():
raise Exception("oh no i ran it")
time.sleep(10)
dont_run()
I saved that file, and ran it. While it was running I commented out the last line and re-saved the file, I then got this error:
$ py main.py
Traceback (most recent call last):
File "main.py", line 10, in <module>
# dont_run()
File "main.py", line 6, in dont_run
raise Exception("oh no i ran it")
Exception: oh no i ran it
So I think what must have happened here is that you ran the file before the file was saved to disk (perhaps a race between two network requests and you got unlucky).
[autoreload of R17_Plot_profiles failed: Traceback (most recent call last):
File "/home/jdrevon/anaconda3/lib/python3.7/site-packages/IPython/extensions/autoreload.py", line 244, in check
superreload(m, reload, self.old_objects)
File "/home/jdrevon/anaconda3/lib/python3.7/site-packages/IPython/extensions/autoreload.py", line 378, in superreload
module = reload(module)
File "/home/jdrevon/anaconda3/lib/python3.7/imp.py", line 314, in reload
return importlib.reload(module)
File "/home/jdrevon/anaconda3/lib/python3.7/importlib/__init__.py", line 168, in reload
raise ModuleNotFoundError(f"spec not found for the module {name!r}", name=name)
ModuleNotFoundError: spec not found for the module 'R17_Plot_profiles'
]
This problem occurs in Python 3.7 on Spyder when I modify part of my code and I press F9 to execute some parts of it. Even if I execute my main python file which load every sub-python .py codes I have this error message. However, It does not stop the code from running but the file didn't save the modifications made. This is the first times it happens since I imported the 'R17_Plot_profiles.py' python file.
However in the case where I execute the main profile, I have the previous message but I have also the following one :
Reloaded modules: reconstruct, R2_Spice_Kernels, R4_Offset_Correction, R5_State_Vectors_twoway_v2, R6_Foot_Print, R7_Framework_Conversion,
R8_BendAng_ImpParam_up, R8_BendAng_ImpParam_dn, R9_Avg_BendAng_ImpParam, R10_Altitude_above_Ellipsoid, R11_Refractivity_and_Bending_Radius_v2,
R12a_Electron_Density_up, R12b_Electron_Density_dn, R12_Electron_Density_avg, R13_Neutral_Number_Density,
R14_Pressure_and_Temperature, R16_Errors, R17_Plot_profiles,
R3_Read_L2_Data_v2
So I don't know how to solve the autoreload problem. I've tried to downgrade my IPython version to 7.5 like some people tried and succeed but for me It doesn't change anything.
Edit : It's important to notice that if I restart the kernel, the first execution do not show the error message until I modify directly the python code.
I did few modifications yesterday and it seems to be solved. Since the error occurence started to be random at some points, i'm not sure for 100% but it can maybe solve the issue.
The problem could be came from the use of os.chdir function, I replaced it by specifying the entire path to save my figures until to go to the path using os.chdir and then save my figures in it.
It can maybe produce some conflicts of path and repository to find the python script which is no longer in the path where the script is currently working and therefore can't find it in order to save the modifications.
I keep you informed if at some point the error comes back but for now after some trials the error didn't show up anymore.
I created a maya python toolchain for my team. All works well, just on one machine i seem to have problems. I narrowed it down to the print command. Like this test library called "temp.py":
import os
# from pymel.core import *
print "Hello"
after importing it with
import temp
it produces this output (only on that one computer!):
// Error: 9
# Traceback (most recent call last):
# File "<maya console>", line 1, in <module>
# File "C:\maya_scripts\temp.py", line 4, in <module>
# print "Hello"
# IOError: [Errno 9] Bad file descriptor //
I've tried Maya Version 2016, 2016.5 and 2017. All the same result. Python 2.5 as standalone hasn't got that problem. To me that sounds like some kind of configuration problem, but then again it behaves the same over 3 different maya installations, so deleting the prefs didn't help either.
It's hard to know what's really happening here. But try this
import sys
sys.__stdout__.write("hello")
sys.__stdout__.write(str(sys.stdout))
Then check your output window (not the listener). In a vanilla maya you'd expect to see something like
<maya.Output object at 0x00000217E827FC10>
after "hello". If you see something else, some script has tried to hijack sys.stdout in this installation. You can probably work around it by creating an environment variable called MAYA_SKIP_USERSETUP_PY, setting it to 1, and restarting -- that should stop whatever script is being naughty from autoloading.
This ought to reset it to what you're looking for:
import maya.utils as utils
sys.stdout = utils.Output()
However you need to comb through the scripts on that machine and find out who is messing with sys.stdout behind your back
The error is from your module, you may overwrite the print function
maya 2016 is python 2.7.6 and maya 2017 is in python 3.x
on 2017 you must use print("")
I have some code that's been untouched since last November, its worked fine this whole time, until now. as far as i know, nothing else has been changed on this host.
The error:
Traceback (most recent call last):
File "/scm/pvcs/scripts/pyscripts/update_scr_20.py", line 115, in <module>
updateSCR(SCR, myDeployer, myDeployerID, myEnv, myEnvID, deployTime)
File "/scm/pvcs/scripts/pyscripts/update_scr_20.py", line 33, in updateSCR
client = Client(url=SBM_WSDL, location=SBM_ENDPOINT, timeout=180)
File "build/bdist.linux-x86_64/egg/suds/client.py", line 109, in __init__
File "build/bdist.linux-x86_64/egg/suds/cache.py", line 145, in __init__
File "build/bdist.linux-x86_64/egg/suds/cache.py", line 277, in checkversion
File "build/bdist.linux-x86_64/egg/suds/cache.py", line 251, in clear
OSError: [Errno 13] Permission denied: '/tmp/suds/suds-7962357479995671267-document.px'
I've changed the file permissions to 777, still get the same 'permission denied' error.
This error is raised when suds is run in multiuser environment. Your user (using whom you are running a script) must not have an ownership of that directory. Also try turning the cache off or change the cache directory.
Can you share your part of code which is causing the error.? You should catch the exception and see the full error log.
This is essentially a less than perfect design decision on the part of the python soap client. It by default creates a file in a global space (/tmp/suds) that is owned by a single user, and that locks out other users from using the python soap client. If you chmod /tmp/suds/* to allow the world access it will work (what IBM recommends in their OpenStack product) ... or clean up after the use of the client by deleting the garbage it leaves behind.
The soap client ought to have created the suds directory in the users space (under /home/username) so each user would have their own, or if it really ought be a global resource it should have used open access to the file. By doing neither, it probably has caused a lot of time lost by many a user. I'd call it a bug. Something that costs users time and is easily fixed.
I am having trouble porting a working, Windows Python application to Linux. I am having some problems, because I did not write the code and am just learning Python. I am having trouble fixing the issues that it keeps throwing up. So here is a kind of error that right now I am stuck with
Traceback (most recent call last):
File "alpha_beta", line 237, in <module>
main()
File "alpha_beta", line 185, in main
ABCCmd()
File "alpha_beta.py", line 74, in ABCCmd
File "C:\softs\Python\Lib\shutil.py", line 80, in copy
File "C:\softs\Python\Lib\shutil.py", line 47, in copyfile
IOError: [Errno 13] Permission denied: '/myPath/XFiles.bin.addr_patched
Any pointers on how to fix it will be much appreciated
Edit:
1) What I mean by I am stuck is, the traceback of the error goes to C:\softs\Python\Lib but actually I am currently executing this code in Ubuntu. Why would the traceback reference to windows library
2) Another thing that bothers me is it says there is an IOError.But when I try to add permission for the denied one it gives me a chmod: changing permissions of /myPath/xFiles.bin.addr_patched': Operation not permitted
Edit 2:
I had commented out a module because I thought it wasn't very useful. Since Now I am anyway discussing the porting issues, I thought I can bring up this additional problem as well since I think the issue is the same and the fix should be similar. On including #pdb module in the python code, I get the following error
traceback (most recent call last):
File "alpha_beta", line 6, in <module>
import pdb
File "C:\softs\Python\Lib\pdb.py", line 14, in <module>
File "C:\softs\Python\Lib\pprint.py", line 39, in <module>
ImportError: No module named cStringIO
I looked at the importer_Cache and looks like this
'': None, '/usr/lib/python2.6/plat-linux2': None, '/usr/lib/python2.6/': None
'/usr/lib/pymodules/python2.6/gtk-2.0': None, '/usr/lib/python2.6/lib-tk': None,
'/usr/lib/python2.6/lib-old': <imp.NullImporter object at 0x7f1269048070>, '/usr/
/python2.6/dist-packages/gtk-2.0': None, '/usr/lib/python2.6/dist-packages/PIL': None,
'/usr/local/lib/python2.6/dist-packages': None, '/usr/lib/python2.6/dist-packages':
None
*SOLVED : There was a weird wrapper in the script which was causing the python script to execute from a different location. Still don't understand how though. After modifying my script to just directly execute as python myScript.py it runs fine. Thank you all anyway for the help
The mixture of Windows and Unix style paths in your error messages makes me think that you may have some filenames that are hard coded or manually created using os specific path separators ('\' or '/'). If you can figure out where the gOptions.inputTf and gWorkingTfFile values are assigned you should look into using os.path.join to help you use the correct paths.
from os.path import join
file = join('A', 'B')
# 'A/B' on unix systems
# 'A\B' on windows systems