Hans de Goede wrote: > On 10/06/2009 11:54 AM, Jim Meyering wrote: >> Hans de Goede wrote: >>> Modify libparted/arch/linux.c _partition_get_part_dev() to not call >>> _device_stat() but instead use stat directly, as _device_stat() calls >>> the libparted exception handler and we don't want this here, the only caller >>> of _partition_get_part_dev() is _partition_is_mounted(), which in turn only >>> gets called by linux_partition_is_busy(), and we don't want to "throw" >>> exceptions from ped_partition_busy() >>> >>> This issue was noticed in combination with pyparted as used by anaconda, see: >>> https://bugzilla.redhat.com/show_bug.cgi?id=527035#c10 >> >> Hans, >> >> I'm adding this to your commit. >> If you'd like to adjust the wording, please let me know ASAP: >> > > The wording is fine. > > I wonder about the specific mention of the trouble this caused for anaconda, > is throwing exceptions not something which ped_partition_busy() should not > do in general? Just curious. Nothing against anaconda. My goal is to provide a little more info, in an attempt to help other users of libparted know if they too would be affected. As to whether C library code should "throw exceptions", well... Let's just say I prefer libraries with functions that don't do that. Whether it's in line with the rest of libparted is another story. It's hard to know what was intended. No spec, few comments. Was the goal of the exception really just to print a diagnostic? Or was it actually to give an interactive user an opportunity to cancel/quit or continue? In this case, your change -- eliminating the probably-rare diagnostic -- seems fine. I see that the function name is actually ped_partition_is_busy. I've corrected that in NEWS. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list