summaryrefslogtreecommitdiff
path: root/open_issues/open_symlink.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/open_symlink.mdwn')
-rw-r--r--open_issues/open_symlink.mdwn14
1 files changed, 13 insertions, 1 deletions
diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn
index 20e4a4fe..f71109a9 100644
--- a/open_issues/open_symlink.mdwn
+++ b/open_issues/open_symlink.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -10,9 +10,21 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_glibc]]
+
# IRC, freenode, #hurd, 2012-01-02
<pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY |
O_NOFOLLOW) does not fail with ELOOP?
<youpi> pinotree: iirc there is code for it, maybe not the same behavior as
on linux
+
+
+## IRC, OFTC, #debian-hurd, 2013-05-08
+
+ <pinotree> the hurd issue is that Q_NOFOLLOW seems broken on symlinks, and
+ thus open(symlink, O_NOFOLLOW) doesn't fail with ELOOP
+ <youpi> I don't really see why it should fail
+ <youpi> since NOFOLLOW says not to follow the symlink
+ <pinotree> yeah, but you cannot open a symlink
+ <youpi> ah right ok
+ <youpi> interesting :)