Re: [web2py] getting "<type 'exceptions.IOError'> [Errno 13] Permission denied" over and over

[Johann Spies]

On 3 September 2014 23:31, JorgeH <jorg...@gmail.com> wrote:

I discovered that by cleaning errors, cache and sessions, its work again. But now Im getting the error like every other time I test.

Any hints??

Which user owns web2py/applications/<your_app>/models?

Regards

Johann

--
Because experiencing your loyal love is better than life itself,
my lips will praise you.  (Psalm 63:3)

[JorgeH]

It's on Windows. The default user.

Sometimes it works and sometimes not.

[JorgeH]

It seems to have something to do with

Traceback (most recent call last):
  File "/home/mdipierro/make_web2py/web2py/gluon/restricted.py", line 220, in restricted
  File "C:/web2py/applications/ZenuToolkit/models/zenu.py", line 133, in <module>
    readable=False, writable =False),
  File "/home/mdipierro/make_web2py/web2py/gluon/dal.py", line 8223, in define_table
  File "/home/mdipierro/make_web2py/web2py/gluon/dal.py", line 8260, in lazy_define_table
  File "/home/mdipierro/make_web2py/web2py/gluon/dal.py", line 1132, in create_table
  File "/home/mdipierro/make_web2py/web2py/gluon/dal.py", line 1257, in migrate_table
  File "/home/mdipierro/make_web2py/web2py/gluon/dal.py", line 1265, in save_dbt
  File "/home/mdipierro/make_web2py/web2py/gluon/dal.py", line 793, in file_open
  File "/home/mdipierro/make_web2py/web2py/gluon/portalocker.py", line 122, in __init__
IOError: [Errno 13] Permission denied

Error snapshot

<type 'exceptions.IOError'>([Errno 13] Permission denied)

the writable and readable permissions in the fields.

On Thursday, September 4, 2014 12:11:10 PM UTC-5, JorgeH wrote:

It's on Windows. The default user.

Sometimes it works and sometimes not.



On Thursday, September 4, 2014 2:22:47 AM UTC-5, Johann Spies wrote:

[JorgeH]

It happens on version 2.9.9 too

Version

web2py™	Version 2.9.9-stable+timestamp.2014.09.08.13.16.54
Python	Python 2.7.6: C:\web2py\web2py.exe (prefix: C:\Python27)

Traceback

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Traceback (most recent call last

): File "gluon/restricted.py", line 221, in restricted File "C:/web2py/applications/ZenuToolkit/models/zenu.py", line 144, in <module> db.agua.fuente.requires=IS_IN_SET(["Acueducto", "Subterranea", "Superficial", "Lluvia"], multiple = True) File "gluon/dal.py", line 8494, in __getattr__ File "gluon/dal.py", line 8426, in lazy_define_table File "gluon/dal.py", line 1134, in create_table File "gluon/dal.py", line 1258, in migrate_table File "gluon/dal.py", line 1266, in save_dbt File "gluon/dal.py", line 799, in file_open File "gluon/portalocker.py", line 122, in __init__

IOError: [Errno 13] Permission denied

[JorgeH]

Worse thing is that everytime this happens. Web2py freezes and I have to shut the console and reboot it. Otherwise it doesn't work anymore.

[Leonel Câmara]

Jorge do you have pywin32 installed? That is very weird.

[JorgeH]

Yes I do.

But I am using the web2py package for win.

Theoretically, it should not interfere ..

[Derek]

Line 122 is for posix_lock, and that should not be occurring because you are on windows. That's very strange.

For some reason os.name must be returning something other than 'nt'.

[Derek]

just out of curiosity, what version of windows?

Here's the possible values for os.name... 

'posix', 'nt', 'os2', 'ce', 'java', 'riscos'

so it looks like 'ce' or 'posix' could be returned...

Is it Windows CE? 

[JorgeH]

windows 7 32 bit

Thanks for your answer

Any help is very appreciated.

[Derek]

ah, i see that web2py is not using the latest version of portalocker. ok, so line 122 of portalocker is "self.file.truncate()" so you don't have permission to truncate a file. And apparently the file does is not being opened in append mode...

so what file? hmm, judging from the trace, it's going to be a database .table file.

so check permissions on the database .table files...

also i noticed that web2py and portalocker are interacting strangely. opening a file in 'w' mode will already do the seek(0) and truncate. Why portalocker does it again is pointless to me....

[JorgeH]

• File C:\web2py\gluon\dal.py in file_open at line 799 code arguments variables

  Function argument list

  (self=<gluon.dal.SQLiteAdapter object>, filename=r'C:\web2py\applications\ZenuToolkit\databases\c8b669d15150d7109e5f7ab36744a5b7_agua.table', mode='w', lock=True)

• File C:\web2py\gluon\portalocker.py in __init__ at line 122 code arguments variables

  Function argument list

  (self=<gluon.portalocker.LockedFile object>, filename=r'C:\web2py\applications\ZenuToolkit\databases\c8b669d15150d7109e5f7ab36744a5b7_agua.table', mode='w')

[Leonel Câmara]

Derek it's because portalocker changes 'w' to 'a' when it opens the file so then it has to emulate 'w'.  

  

I have no freaking idea why portalocker does this instead of just using 'w', I'm guessing it was done to get around a quirk that once existed.  

  

OTOH I don't see why truncate is not being allowed and why I have never had this problem.  

[JorgeH]

Hmmm

For a moment I thought it was resolved

But the problem continues...

:(

 

[Simon Ashley]

quite painful on win8.1 and 

web2py™	Version 2.9.5-stable+timestamp.2014.03.16.02.35.39
Python	Python 2.7.7: C:\Anaconda\python.exe (prefix: C:\Anaconda)

 

[Leonel Câmara]

I'm going to give you guys a simple workaround - Uninstall pywin32. That way there will be no file locking. Which should be no problem for a development machine. If this is a production machine just turn migrations off.

That said it would be nice to know what the problem is exactly. Probably some weird async stuff going on here since it looks so random.

I wonder if we can solve this by simply, on windows, opening the file using os.O_EXCL.

[JorgeH]

Definitely , looks sooo Random..

[Leonel Câmara]

One thing we can do to avoid this kind of weird async stuff from happening (LockFileEx is asynchronous if the file is not opened in synchronous mode) is to use LOCKFILE_FAIL_IMMEDIATELY and then actively wait.

Sort of the approach followed by oauth2client:

https://github.com/google/oauth2client/blob/master/oauth2client/locked_file.py

It's uglier but if it at least works it's an improvement.

[JorgeH]

Well I am already moving the app to mysql, the problem dissapeared.

One thing I suspect has something to do with this issue, is that in the model file I was using has 13 table definitions. Even using lazy_tables = true, this error was rising up. Almost every time pointing to a different line of the model.

[Leonel Câmara]

It may seem like it disappeared but it hasn't because the database has nothing to do with it, it's the files web2py uses to save the table structure and perform migrations which are creating the problem. 13 table definitions doesn't seem excessive to me and shouldn't create any problems.

[JorgeH]

Hmmm

I tend to  think that the combination of SQLite + Windows, may have most or everything to do with the prob with portalocker.

Time will tell

[Niphlod]

SQLite has nothing to do with portalocker ....

[JorgeH]

Ok

I ran out of hypothesis then

[Simon Ashley]

Had installed the anaconda distribution so couldn't uninstall just pywin32. (needed it for other apps). No mention of it in the 8.1 registries. Renamed all pywin32 related files to non-descipt file extentions (on Win8.1) and have hammered it for the last 8 hours without issue. Another machine with win7, without modification, still sucks. Both development machines.

[Willoughby]

I'm late to this thread but one issue I always run into with web2py on Windows (well, anything with SQLite) are virus scanners randomly locking files.  Especially if they're corporate network machines.  That's another avenue you might look into.

[Gene]

Encountered the same ticket on windows 8.1, web2py 2.9. 'Fixed' by uninstalling McAfee, no tickets thereafter.

[Dave S]

On Thursday, May 28, 2015 at 9:33:28 PM UTC-7, Gene wrote:

Encountered the same ticket on windows 8.1, web2py 2.9. 'Fixed' by uninstalling McAfee, no tickets thereafter.

You might not have to uninstall; McAfee, AIUI, does provide the ability to exclude certain directories from scanning.  This issue comes up in the Mercurial forums, too, and in general you don't want scanning (or the OS indexing) of repositories.

Thanks for the confirming experience, though.

/dps