| www.delorie.com/archives/browse.cgi | search |
Hi! August 12, 1999 Chris Faylor cgf AT cygnus DOT com wrote: >> Attached patch make stat functions recognize UNC paths as remote. It >>speeds up fstat operations on remote drives, which are not mapped to >>drive letters. CF> Does this patch still operate correctly with the old "\\a" style method CF> for handling drives? if you mean paths like \\.\c:\temp\ then answer is "yes" -- it treats them as local ones. Are there any other possible UNC notation? Current implementation of stat_worker relies on the fact that first symbol of win32 name is drive letter. Generally, it's not true. >>BTW, what do you think of providing porters with some sort of "lite" >>versions of stat functions? Retrieving all stat information isn't >>always necessary, and opening file to get it's st_ino and scanning >>directory to get st_nlinks are quite time-consuming operations. CF> I don't know how this could be used. Would you define stat as CF> "stat_lite" when you compile an application? no, it would be too straightforward. Application may still need to have st_ino and st_nlinks sometimes. I meant that when porting application one could choose between slow and informative stat and fast stat_lite, if application don't need those specific fields. I've tried to recompile midnight commander replacing stat with stat_lite in directory-loading code -- it runs several times faster, especially on slow network drives. Whether to do such substitution global for all application or not -- it's up to porter. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |