> i need NOT to "reset your expectations" because if i would > start to expect that it is mordern everywhere to replace working > things with new stuff which is NOT READY i should throw > away all my computers and search a job in a church Well you do what you feel is best for you. Working at a church can be a rewarding experience, it may in fact help you develop a modicum of empathy for other human beings in a way that living entirely through electronic interaction cannot. I personally enjoy the time I volunteer at my church Anyways.... I've tried to point you to a modicum of historical context to give you some breadcrumbs to follow to gain some perspective on how long people (not just our distribution) have been struggling to resolve the problems associated with relying on /etc/mtab. The reality is "mounting" over the years in linux has seen a lot of changes in the past 10 years with more and more kernel level fake filesystems that are not attached to block devices show up. Many people have come to understand that the best solution to all the problems is to rely on the kernel's own knowledge of the mount points and to stop relying on /etc/mstab as constructed artificially which can get out of sync with the kernel's mounting information. Some of the historic problems with relying on mtab has been encoded in the mount manpage for awhile now(well before Fedora even considered moving away from mtab) and I've personally pointed you to an upstream list discussion concerning the problems relying on mtab dating back to 2007. And to be clear Fedora isn't the first distribution to turn /etc/mtab into a symlink. Hell, even _historic_ "linux from scratch" manual has instructions that tell people to turn mtab into a symlink into /proc/mounts. http://archive.linuxfromscratch.org/lfs-museum/3.3/LFS-BOOK-3.3-HTML/index.html That dates from 2003!!!!!! 2003!!!!!!! There have been people out there, smart do-it-yourselfers working with LFS to build up their own linux distro from sources who have been making the very change that is frustrating you in 2003. is there a problem with bind mount handling? Yes Was it caught in testing? Seems like it wasn't. Does Fedora make any effort to test bind mounts as part of organized pre-release QA? I'm not aware that we do as our pre-release QA is quite narrowly scoped to ensure default install configs as we don't have the resources to test all possible configurations and command options. Did anyone who makes use of bind mounts day to day in our userbase flag this ahead of release? I didn't and I really can't lay the blame at the feet of developers for shipping something "not ready" when I myself, who was actively testing for breakage, didn't catch this. And make no mistake the solution to bind mount handling and representation moving forward will not depend on reverting to using the constructed information in /etc/mtab and will have to depend on the kernel's /proc/mounts. Tools that relied on mtab's understanding of what a bind mount was (and it seems also the user option if I'm reading the mount manpage correctly.) There has been years of discussion on the issue of mtab versus /proc/mounts outside of our specific distribution channels, and there is no getting around it that the long term solution is to rely on the kernel's own representation of mounts. Though I wonder, since /etc/mtab is just a symlink. is the mount command we ship still able to write to /etc/mtab if a local admin decided to revert and make /etc/mtab a normal file again. Would our mount command then update that file as per the legacy way? because really that is exactly what you want to do on your system. If our mount command will still attempt to write to /etc/mtab once its a real file again, maybe things will work for you as expected. -jef You've only taken notice because its finally impacted you. I think its ready enough to ship I believe your definition of ready is incompatible with the release model Fedora has chosen. Your expectation is that new things work exactly the same and have detailed backwards compatability. That's hasn't been true _ever_ in any system I've had the pleasure of doing upgrades across major releases. windows, qnx,vms,mac os, linux.... tons and tons and tons of subtle syntax channges in shipped functionality that resulted in breakage in my "working" code on all those systems in different places at different times. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
