Hi, > > > > > The rename() will fail. > > > > > > > > Because? > > > > > > > POSIX. > > > > More specifically? > > > > And anyhow, I thought we were talking about the Linux kernel?! > > > If you don't know why rename() might fail, you really shouldn't be > mucking around with this kind of code. see, that's why I am trying to consult with you before trying to "muck around with this kind of code". However, you may have noticed that this message of yours was rather much void of any information that could help me in doing so. Also, you are welcome to fix the bug I was reporting using your understanding of the code, so I don't have to "muck around with this kind of code" - I really am not all that keen on doing so. > > > > > > > Or when racing with devmapper which creates /dev/mapper/foo devices at > > > > > > > basically the same time as udev. > > > > > > > > > > > > Seriously? How is a piece of code that does the existence check and > > > > > > the subsequent action depending on the result of that check non-atomically > > > > > > supposed to help avoid some race condition resulting from possible > > > > > > concurrent creation of a device node?! > > > > > > > > > > > Read the code and find out. It works. > > > > > > > > Guess how I found out that it can not work. > > > > > > > I don't know, you haven't given any detail of any problems you've > > > encountered. > > > > I haven't "encountered any problems", nor have I claimed to have > > "encountered any problems". > > > > You stated that the codepath in udev-node.c for the case when a > > device node does already exist was somehow there for the case > > when udev races with devmapper. I noted that that codepath is not > > of any use in such a case, and that your argument thus is invalid. > > > Since I wrote this code, and the code in devmapper, and have not only > strenuously tested it; but have at least 18 million for whom it works > every day, I'd argue that my argument is quite valid ;-) No, arguments are not valid because something unrelated is true. Florian -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
