search for: nfileindexlow

...ote: > However, looking over the FileManager code a little more I'm not even sure > using the path is the best solution, it seems it would be better to use > inode like the unix code does. Windows doesn't support inode (the s_ino > field in stat), but it does have nFileIndexHigh/nFileIndexLow which are > exposed via ::GetFileInformationByHandle and is basically the same thing. One question I would have about that is whether stat actually opens the file under the hood. GetFileInformationByHandle requires an open file handle, which could be expensive depending on the situation. I...

...wever, looking over the FileManager code a little more I'm not even sure >> using the path is the best solution, it seems it would be better to use >> inode like the unix code does. Windows doesn't support inode (the s_ino >> field in stat), but it does have nFileIndexHigh/nFileIndexLow which are >> exposed via ::GetFileInformationByHandle and is basically the same thing. > > One question I would have about that is whether stat actually opens > the file under the hood. GetFileInformationByHandle requires an open > file handle, which could be expensive depending...

...t answer than tolower?) However, looking over the FileManager code a little more I'm not even sure using the path is the best solution, it seems it would be better to use inode like the unix code does. Windows doesn't support inode (the s_ino field in stat), but it does have nFileIndexHigh/nFileIndexLow which are exposed via ::GetFileInformationByHandle and is basically the same thing. This would require refactoring FileSystemStatCache to use a new structure in place of stat that could be shared between Windows and Unix. This would be a lot of small changes but seems like it would be fairly straig...

...> > However, looking over the FileManager code a little more I'm not even sure > using the path is the best solution, it seems it would be better to use > inode like the unix code does. Windows doesn't support inode (the s_ino > field in stat), but it does have nFileIndexHigh/nFileIndexLow which are > exposed via ::GetFileInformationByHandle and is basically the same thing. > This would require refactoring FileSystemStatCache to use a new structure in > place of stat that could be shared between Windows and Unix. This would be a > lot of small changes but seems like it wo...

...han tolower?) > > However, looking over the FileManager code a little more I'm not even sure using the path is the best solution, it seems it would be better to use inode like the unix code does. Windows doesn't support inode (the s_ino field in stat), but it does have nFileIndexHigh/nFileIndexLow which are exposed via ::GetFileInformationByHandle and is basically the same thing. This would require refactoring FileSystemStatCache to use a new structure in place of stat that could be shared between Windows and Unix. This would be a lot of small changes but seems like it would be fairly straig...

towlower doesn't seem to work with my test string in Cyrillic. This function does locale-specific conversion, is this what we want? Here's the whole thing, with all the calls to ::stat replaced with llvm::sys::fs::Stat. On Fri, Sep 30, 2011 at 8:04 PM, Bryce Cogswell <bryceco at gmail.com> wrote: > You can use _iswupper and _towlower instead of CharLowerBuffW. They don't

You can use _iswupper and _towlower instead of CharLowerBuffW. They don't require windows.h and work with /Za. On Sep 30, 2011, at 12:24 AM, Nikola Smiljanic wrote: > I tried to do the conversion to lowercase inside GetFullPath by adding an additional bool parameter to this function. It's not perfect but seems much better than repeating the whole UTF8 to UTF16 and UTF16 to UTF8