Re[2]: stat_worker patch and suggestion

[Egor Duda <deo@logos-m.ru>]

Hi!

August 12, 1999 Chris Faylor cgf@cygnus.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.

CF> No, I meant exactly what I typed:  \\a .  I did not inspect the patch
CF> or the surrounding code to know if this will affect the *old* way
CF> of accessing drives which is still available, if deprecated.

this patch affect the code dealing with win32-style paths, not unix
paths. it works with the result of path_conv. As far as i remember,
old path_conv code translates //a/dir/file.ext path to a:\dir\file.ext

surrounding code does the followin -- when stat tries to decide if
it's possible to "open" specified entity it has two possible cases.
Either "entity" is a file -- then stat can open it. Or it's a directory,
and then stat can open it too, but only if it's winNT and directory
resides on the local drive. The code which checks for localness or
remoteness of directory don't take into account a possibility that someone
will do something like

mount \\server\volume /net/server/volume

>>>>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.

CF> I understand what you're proposing.  I don't understand how you are
CF> specifically suggesting implementing it.  Obviously, speeding up
CF> cygwin is good, in general.

CF> We certainly don't want to have two versions of the DLL.  That would
CF> be a nightmare.  So what are you proposing?   Using '#define'? Using
CF> an environment variable?  Setting a global variable in the program
CF> itself?  Linking in a separate stat_lite.o object?  Or...???

just exporting 2 new functions from dll. something like cygwin_stat
and cygwin_lstat. then in application i write the following

#if defined (__CYGWIN32__)
extern int cygwin_stat (char *, struct stat*) ;
extern int cygwin_lstat (char *, struct stat*) ;
#endif

/* .... a lot of code skipped .... */

#if defined (__CYGWIN32__)
    res = cygwin_stat (path, buf);
#else
    res = stat (path, buf);
#endif

/* ... a lot of code not using st_ino or st_nlinks */

or something like that.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19