> I think that if ntfs-3g chooses not to ignore this return code, it needs to > be carefull deciced what to do in this siutation. But I would like to ask you > if you could follow this up with Miklos, the author of fuse.
Thanks for your suggestion. > In principle, you do not always want to stop ntfs-3g because some minor error > occured: Filesystems should go to great lenghts (and ntfs-3g does so too) to > not simply abort when an error occors but do the right thing, even if that > means that the error is best ignored because the user is served better by > continuning ntfs filesystem services instead of aborting which causes data > loss if the user has unsafed data for the filesystem which you just aborted. I would like point out situations that the file system software might not be longer executable because of consequences that the runtime environment became inconsistent by programming errors from outside. Unexpected behaviour will not be detected if not all function calls are appropriately checked. > There might be, but ntfs-3g does not exactly have a bad reputation and > neither has Skaza for his excellent and widely-used tool ntfsresize: I do not want to damage the reputation. > If Szaka would not have given error handling very high priority > ntfs-3g would not work as well as it does. I guess that there are a few places left for fine-tuning in the software infrastructure. > Pointing at possible areas of possible improvements like the handling > of this return value fchdir is easy (gcc does it automatically, so you > do not even have to have human intelligence for it) but finding the > right way to do handle it what separates your patch for it from a > useful contribution, IMHO. Some efforts are usual to achieve consensus on complete error and exception handling. > I would not bet that Linux kernel will not switch to C++ anytime soon > and I would like to avoid any relious discussion like using C++ > to use it's exception support. Would the reuse of the software "http://cexcept.sourceforge.net/"; help? Regards, Markus ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
