| 2011-04-09 11:04:44 |
Martina Theuerjahr |
bug |
|
|
added bug |
| 2011-04-09 11:08:35 |
Martina Theuerjahr |
description |
Version: hplip-3.11.3a
When check.py is executed, he first call of check_file() (with argument "crypto.h") leads to an infinite loop within the recursive function utils.walkFiles(). The reason is that this function follows symbolic links to directories.
On my system the directory X contains the symbolic link "Y -> ." because X/Z and X/Y/Z shall be accessible for entries all Z without having the Zs twice on the disk. This is necessary because on program assume Z at X/Z and another program at X/Y/Z.
Anyhow, it is not a good practice to follow symbolic links at a directory descent. Because often an infinite loop starts at it is the case for check.py.
Obviously other users already had the same problem, because there is the question https://answers.launchpad.net/hplip/+question/36267 and the source code for walkFiles() contains the following comment:
# if os.path.islink(fullname):
# fullname = os.path.realpath(os.readlink(fullname))
When the comment chars are removed from these lines check.py works perfectly again.
check_file()
/usr/share/hplip/installer/dcheck.py
walkFiles()
/usr/share/hplip/base/utils.py |
Version: hplip-3.11.3a
When check.py is executed, he first call of check_file() (with argument "crypto.h") leads to an infinite loop within the recursive function utils.walkFiles(). The reason is that this function follows symbolic links to directories.
On my system the directory X contains the symbolic link "Y -> ." because X/Z and X/Y/Z shall be accessible for all entries Z without having the Zs twice on the disk. This is necessary because on program assume Z at X/Z and another program at X/Y/Z.
Anyhow, it is not a good practice to follow symbolic links at a directory descent. Because often an infinite loop starts at it is the case for check.py.
Obviously other users already had the same problem, because there is the question https://answers.launchpad.net/hplip/+question/36267 and the source code for walkFiles() contains the following comment:
# if os.path.islink(fullname):
# fullname = os.path.realpath(os.readlink(fullname))
When the comment chars are removed from these lines check.py works perfectly again.
check_file()
/usr/share/hplip/installer/dcheck.py
walkFiles()
/usr/share/hplip/base/utils.py |
|
| 2011-04-09 11:09:07 |
Martina Theuerjahr |
description |
Version: hplip-3.11.3a
When check.py is executed, he first call of check_file() (with argument "crypto.h") leads to an infinite loop within the recursive function utils.walkFiles(). The reason is that this function follows symbolic links to directories.
On my system the directory X contains the symbolic link "Y -> ." because X/Z and X/Y/Z shall be accessible for all entries Z without having the Zs twice on the disk. This is necessary because on program assume Z at X/Z and another program at X/Y/Z.
Anyhow, it is not a good practice to follow symbolic links at a directory descent. Because often an infinite loop starts at it is the case for check.py.
Obviously other users already had the same problem, because there is the question https://answers.launchpad.net/hplip/+question/36267 and the source code for walkFiles() contains the following comment:
# if os.path.islink(fullname):
# fullname = os.path.realpath(os.readlink(fullname))
When the comment chars are removed from these lines check.py works perfectly again.
check_file()
/usr/share/hplip/installer/dcheck.py
walkFiles()
/usr/share/hplip/base/utils.py |
Version: hplip-3.11.3a
When check.py is executed, he first call of check_file() (with argument "crypto.h") leads to an infinite loop within the recursive function utils.walkFiles(). The reason is that this function follows symbolic links to directories.
On my system the directory X contains the symbolic link "Y -> ." because X/Z and X/Y/Z shall be accessible for all entries Z without having the Zs twice on the disk. This is necessary because one program assume Z at X/Z and another program at X/Y/Z.
Anyhow, it is not a good practice to follow symbolic links at a directory descent. Because often an infinite loop starts at it is the case for check.py.
Obviously other users already had the same problem, because there is the question https://answers.launchpad.net/hplip/+question/36267 and the source code for walkFiles() contains the following comment:
# if os.path.islink(fullname):
# fullname = os.path.realpath(os.readlink(fullname))
When the comment chars are removed from these lines check.py works perfectly again.
check_file()
/usr/share/hplip/installer/dcheck.py
walkFiles()
/usr/share/hplip/base/utils.py |
|
| 2011-04-09 18:04:44 |
Martina Theuerjahr |
summary |
check.py: infinite loop due wrong handling of to symbolic links |
check.py: infinite loop due wrong handling of symbolic links |
|
| 2011-04-10 12:08:58 |
Martina Theuerjahr |
description |
Version: hplip-3.11.3a
When check.py is executed, he first call of check_file() (with argument "crypto.h") leads to an infinite loop within the recursive function utils.walkFiles(). The reason is that this function follows symbolic links to directories.
On my system the directory X contains the symbolic link "Y -> ." because X/Z and X/Y/Z shall be accessible for all entries Z without having the Zs twice on the disk. This is necessary because one program assume Z at X/Z and another program at X/Y/Z.
Anyhow, it is not a good practice to follow symbolic links at a directory descent. Because often an infinite loop starts at it is the case for check.py.
Obviously other users already had the same problem, because there is the question https://answers.launchpad.net/hplip/+question/36267 and the source code for walkFiles() contains the following comment:
# if os.path.islink(fullname):
# fullname = os.path.realpath(os.readlink(fullname))
When the comment chars are removed from these lines check.py works perfectly again.
check_file()
/usr/share/hplip/installer/dcheck.py
walkFiles()
/usr/share/hplip/base/utils.py |
Version: hplip-3.11.3a
When check.py is executed, the first call of check_file() (with argument "crypto.h") leads to an infinite loop within the recursive function utils.walkFiles(). The reason is that this function follows symbolic links to directories.
On my system the directory X contains the symbolic link "Y -> ." because X/Z and X/Y/Z shall be accessible for all entries Z without having the Zs twice on the disk. This is necessary because one program assume Z at X/Z and another program at X/Y/Z.
Anyhow, it is not a good practice to follow symbolic links at a directory descent. Because often an infinite loop starts at it is the case for check.py.
Obviously other users already had the same problem, because there is the question https://answers.launchpad.net/hplip/+question/36267 and the source code for walkFiles() contains the following comment:
# if os.path.islink(fullname):
# fullname = os.path.realpath(os.readlink(fullname))
When the comment chars are removed from these lines check.py works perfectly again.
check_file()
/usr/share/hplip/installer/dcheck.py
walkFiles()
/usr/share/hplip/base/utils.py |
|
| 2013-07-24 07:25:10 |
Wayne E Robertz |
attachment added |
|
utils.py https://bugs.launchpad.net/hplip/+bug/755441/+attachment/3747260/+files/utils.py |
|
| 2020-05-10 10:32:06 |
Daniel Pielmeier |
bug watch added |
|
https://bugs.gentoo.org/show_bug.cgi?id=721018 |
|
| 2020-05-10 10:32:06 |
Daniel Pielmeier |
bug task added |
|
gentoo |
|
| 2020-05-10 10:59:19 |
Bug Watch Updater |
gentoo: importance |
Unknown |
Medium |
|
| 2020-06-02 09:19:43 |
Bug Watch Updater |
gentoo: status |
Unknown |
Fix Released |
|
| 2020-10-06 16:33:35 |
Bug Watch Updater |
gentoo: status |
Fix Released |
Unknown |
|
| 2020-10-06 20:22:10 |
Daniel Pielmeier |
attachment added |
|
Fix infinite loop in walkfiles from base/utils.py https://bugs.launchpad.net/hplip/+bug/755441/+attachment/5418513/+files/hplip-3.20.9-utils-symlink.patch |
|
| 2020-10-06 20:36:04 |
Daniel Pielmeier |
attachment added |
|
Fix infinite loop in walkfiles from base/utils.py https://bugs.launchpad.net/hplip/+bug/755441/+attachment/5418530/+files/hplip-3.20.9-utils-symlink.patch |
|
| 2020-10-23 01:21:00 |
Bug Watch Updater |
gentoo: status |
Unknown |
Fix Released |
|
