https://bugs.freedesktop.org/show_bug.cgi?id=44982
--- Comment #8 from Michael Meeks <[email protected]> 2012-03-09 02:34:50 PST --- yep - it's sad that the interface has to have this unfortunate 'isLink' ambiguity that rather complicates symlinked situations, at least the getLinkTargetURL() is a fully resolved path for this case - ie. following all the symlinks down to the bottom via 'realpath'. Which makes me wonder - why do we have salhelper/inc/salhelper/LinkResolver - which is substantially un-used, and un-necessary for Unix [ cf. the above ]. I'd be eager to bin / deprecate / write-that out. The isDirectory method creates the obvious cleanup in basic/ eg. of removing: basic/source/runtime/methods.cxx-static inline sal_Bool isFolder( FileStatus::Type aType ) But - of course isDirectory is also imprecise in this case, so all this code breaks for symlinked directories as well as symlinked files :-) git grep 'FileStatus.*Link' | nl shows we have only 43 sites checking for and handling Links properly of which 20 are in sal & unit tests ;-) git grep 'getFileStatus' | nl shows 187 hits (100 in sal) ... so - in general we get link handling wrong it seems in a large majority of cases. So - we should fix this by default in our API. IMHO Link handling is a minority use-case, primarily useful on writing files - to make sure we get the semantics of unlink-replace vs. write-through-link right. But of course we do a lot more reading than writing, and ~all directory / file traversing code is broken. Ergo - I think we need to tweak getFileStatus to do a better job by default. I'll attach a patch; I think we need to go around checking each of those 87+ getFileStatus calls, to see if they are non-link-handling, and add a 'true' parameter if they are not. Then (I guess) we don't need to worry about the Link type being returned it never will be. Concrete, actionable thoughts / improvements ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
