This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: os.getcwd failing on LOFS share
Type: crash Stage:
Components: IO, Library (Lib) Versions: Python 3.4, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: miniflow, vstinner
Priority: normal Keywords:

Created on 2017-01-14 17:07 by miniflow, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg285492 - (view) Author: miniflow (miniflow) Date: 2017-01-14 17:07
I am calling os.getcwd and am occasionally seeing failures inside my program.  This is not due to files missing as the files on the share are static.

Eror is:

[Errno 2] No such file or directory

Which is definitely not the case.

Can any sort of trace be done at the time of failure to detect if the issue is with python or the OS?

System is running Debian inside of an Illumos LX zone.
msg285518 - (view) Author: miniflow (miniflow) Date: 2017-01-15 19:23
After performing an strace - it shows that the underlying call to getcwd is indeed returning ENOENT which is not correct.  Does this become a libc bug?
msg285519 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-01-15 20:12
When getcwd() fails with ENOENT, os.getcwd() raises OSError(ENOENT). It's expected and not a bug in Python.

Please report the issue to LOFS.
History
Date User Action Args
2022-04-11 14:58:42adminsetgithub: 73463
2017-01-15 20:12:17vstinnersetstatus: open -> closed

nosy: + vstinner
messages: + msg285519

resolution: not a bug
2017-01-15 19:23:52miniflowsetmessages: + msg285518
2017-01-14 17:07:50miniflowcreate