On 2025-02-28 Lasse Collin wrote:
> On 2025-02-25 Pali Rohár wrote:
> > On Tuesday 25 February 2025 20:11:12 Lasse Collin wrote:
> > > While \\?\...\Partition3 without trailing \ isn't a directory, I
> > > more and more think that it doesn't matter too much if opendir
> > > works on it still. It'
On 2025-02-25 Pali Rohár wrote:
> On Tuesday 25 February 2025 20:11:12 Lasse Collin wrote:
> > While \\?\...\Partition3 without trailing \ isn't a directory, I
> > more and more think that it doesn't matter too much if opendir
> > works on it still. It's so tiny bug that *it alone* isn't worth the
On Tuesday 25 February 2025 20:11:12 Lasse Collin wrote:
> While not about dirent, an old issue in stat() and _stat() is kind of
> related:
>
> MSVCRT's _stat() fails with "directory/", but in POSIX a trailing slash
> should work for directories (and only for directories).
> mingw-w64-crt/stdio/_s
While not about dirent, an old issue in stat() and _stat() is kind of
related:
MSVCRT's _stat() fails with "directory/", but in POSIX a trailing slash
should work for directories (and only for directories).
mingw-w64-crt/stdio/_stat.c provides stat() that, with some exceptions,
removes *one* trail
On 2025-02-24 Lasse Collin wrote:
> I attached a patch to the new dirent.
And now fixed a copypaste error. :-|
--
Lasse Collin
From 7626a912b2d95a090e401b311ec9a3edf771aed7 Mon Sep 17 00:00:00 2001
From: Lasse Collin
Date: Mon, 24 Feb 2025 17:35:03 +0200
Subject: [PATCH] ... Fix copypaste error
On 2025-02-23 Lasse Collin wrote:
> On 2025-02-23 Pali Rohár wrote:
> > WinAPI \\?\ has meaning to not do any normalization, so consumer
> > should not add or remove some characters.
[...]
> In the new dirent, GetFullPathNameW converts mixed \/ usage to \, then
> * is appended and FindFirstFileW
On 2025-02-23 Pali Rohár wrote:
> This happens when people do not know difference and mix things
> together. Then the result is even larger mess. WinAPI \\?\ has
> meaning to not do any normalization, so consumer should not add or
> remove some characters.
:-/ Quite possibly people just think abou
On Sunday 23 February 2025 17:46:26 Lasse Collin wrote:
> On 2025-02-22 Pali Rohár wrote:
> > On Saturday 22 February 2025 18:12:36 Lasse Collin wrote:
> > > On 2025-02-22 Pali Rohár wrote:
> > > > On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> > > > > On 2025-02-18 Pali Rohár wrot
On 2025-02-22 Pali Rohár wrote:
> On Saturday 22 February 2025 18:12:36 Lasse Collin wrote:
> > On 2025-02-22 Pali Rohár wrote:
> > > On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> > > > On 2025-02-18 Pali Rohár wrote:
> > > > > On Tuesday 18 February 2025 23:32:54 Lasse Collin
On Saturday 22 February 2025 18:12:36 Lasse Collin wrote:
> On 2025-02-22 Pali Rohár wrote:
> > On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> > > On 2025-02-18 Pali Rohár wrote:
> > > > On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > > > > On 2025-02-18 Pali Rohár wro
On 2025-02-22 Pali Rohár wrote:
> On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> > On 2025-02-18 Pali Rohár wrote:
> > > On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > > > On 2025-02-18 Pali Rohár wrote:
> > > > > Just one test case, can you check that your new re
On Saturday 22 February 2025 16:03:42 Lasse Collin wrote:
> On 2025-02-18 Pali Rohár wrote:
> > On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > > On 2025-02-18 Pali Rohár wrote:
> > > > Just one test case, can you check that your new readdir()
> > > > function is working correctly on
On 2025-02-18 Pali Rohár wrote:
> On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > On 2025-02-18 Pali Rohár wrote:
> > > Just one test case, can you check that your new readdir()
> > > function is working correctly on these two paths?
> > >
> > > \\?\GLOBALROOT\Device\Harddisk0\Parti
On 2025-02-18 Pali Rohár wrote:
> On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> > With one partition, opendir fails with EIO, and GetLastError returns
> > ERROR_UNRECOGNIZED_VOLUME (1005). That seems to mean that there's no
> > recognized file system. I don't know if that error code sh
On Tuesday 18 February 2025 23:32:54 Lasse Collin wrote:
> On 2025-02-18 Pali Rohár wrote:
> > Just one test case, can you check that your new readdir() function is
> > working correctly on these two paths?
> >
> > \\?\GLOBALROOT\Device\Harddisk0\Partition1\
> > \\?\GLOBALROOT\Device\HardiskVolume
On 2025-02-18 Pali Rohár wrote:
> Just one test case, can you check that your new readdir() function is
> working correctly on these two paths?
>
> \\?\GLOBALROOT\Device\Harddisk0\Partition1\
> \\?\GLOBALROOT\Device\HardiskVolume1\
>
> If you are not familiar with NT paths encoded in WinAPI paths
On 2025-02-18 Lasse Collin wrote:
> Python's stat.S_IFBLK and stat.S_ISBLK(mode) use the values from
> . Thus, MSYS2-Python uses 0x6000 and UCRT64-Python
> uses 0x3000.
Python/fileutils.c hardcodes 0x6000:
https://github.com/python/cpython/blob/51d4bf1e0e5349090da72721c865b6c2b28277f3/Python
On Tuesday 18 February 2025 18:48:40 Lasse Collin wrote:
> On 2025-02-17 Pali Rohár wrote:
> > On Monday 17 February 2025 17:37:17 Lasse Collin wrote:
> > > I suppose lstat() shouldn't follow any reparse points.
> >
> > That is a question for which I do not have answer.
>
> One would need to fi
On 2025-02-17 Pali Rohár wrote:
> On Monday 17 February 2025 17:37:17 Lasse Collin wrote:
> > I suppose lstat() shouldn't follow any reparse points.
>
> That is a question for which I do not have answer.
One would need to figure out what is the least surprising behavior.
> Why should follow:
>
On Monday 17 February 2025 17:37:17 Lasse Collin wrote:
> On 2025-02-16 Pali Rohár wrote:
> > On Sunday 16 February 2025 19:32:24 Lasse Collin wrote:
> > > (There's no lstat() to detect symlinks or readlink() to read them.)
> >
> > I know. Maybe for future it would be nice to have lstat() call.
>
On 2025-02-16 Pali Rohár wrote:
> On Sunday 16 February 2025 19:32:24 Lasse Collin wrote:
> > (There's no lstat() to detect symlinks or readlink() to read them.)
>
> I know. Maybe for future it would be nice to have lstat() call.
> Implementation can be straightforward, open path as reparse point,
On Sunday 16 February 2025 19:32:24 Lasse Collin wrote:
> On 2025-02-16 Pali Rohár wrote:
> > On Sunday 16 February 2025 12:23:56 Lasse Collin wrote:
> > > On 2025-02-15 Pali Rohár wrote:
> > > > IMHO, we should not use FILE_ATTRIBUTE_* for determining d_type
> > > > (except the FILE_ATTRIBUTE_DI
On 2025-02-16 Pali Rohár wrote:
> On Sunday 16 February 2025 12:23:56 Lasse Collin wrote:
> > On 2025-02-15 Pali Rohár wrote:
> > > IMHO, we should not use FILE_ATTRIBUTE_* for determining d_type
> > > (except the FILE_ATTRIBUTE_DIRECTORY which defines directory).
> > > Those are basically attrib
On Sunday 16 February 2025 12:23:56 Lasse Collin wrote:
> On 2025-02-15 Pali Rohár wrote:
> > IMHO, we should not use FILE_ATTRIBUTE_* for determining d_type
> > (except the FILE_ATTRIBUTE_DIRECTORY which defines directory). Those
> > are basically attributes which do not define file type in POSIX
On 2025-02-15 Pali Rohár wrote:
> IMHO, we should not use FILE_ATTRIBUTE_* for determining d_type
> (except the FILE_ATTRIBUTE_DIRECTORY which defines directory). Those
> are basically attributes which do not define file type in POSIX sense
> at all. There are still few attributes not defined yet,
On Saturday 15 February 2025 19:25:21 Lasse Collin wrote:
> I attached preview patches for a new version that uses FindFirstFileW.
> Perhaps these could be the final version, but I would appreciate if you
> had time to comment these shortly at some point (no rush).
>
> The main change is just one
I attached preview patches for a new version that uses FindFirstFileW.
Perhaps these could be the final version, but I would appreciate if you
had time to comment these shortly at some point (no rush).
The main change is just one huge patch instead of multiple smaller
pieces. :-( Unfortunately I t
On 2025-01-28 Pali Rohár wrote:
> I think that for excluding 8.3 names you mean to use FindExInfoBasic
> level instead of FindExInfoStandard when doing FindFirstFileExW().
>
> Level FindExInfoBasic is supported since Windows 7 and I think that
> readdir() could be still useful also on Windows XP.
On Sunday 26 January 2025 21:26:49 Lasse Collin wrote:
> On 2025-01-26 Pali Rohár wrote:
> > Maybe it could be a good idea to look into last released version of
> > source code for UCRT. Such ___lc_codepage_func() / CP_UTF8 /
> > AreFileApisANSI() / CP_ACP / CP_OEMCP should be there too (if it was
On Monday 27 January 2025 16:49:26 Lasse Collin wrote:
> Another behavior difference happens with invalid multibyte strings.
> I tested with UTF-8 in application manifest. A file named L"_\uFFFD_"
> exists.
>
> The UCRT functions fail if given invalid UTF-8:
>
> fopen("_\x80_", "r");
> _o
Another behavior difference happens with invalid multibyte strings.
I tested with UTF-8 in application manifest. A file named L"_\uFFFD_"
exists.
The UCRT functions fail if given invalid UTF-8:
fopen("_\x80_", "r");
_open("_\x80_", O_RDONLY);
// _findfirst fails too
GetLastError() re
On 2025-01-26 Pali Rohár wrote:
> Maybe it could be a good idea to look into last released version of
> source code for UCRT. Such ___lc_codepage_func() / CP_UTF8 /
> AreFileApisANSI() / CP_ACP / CP_OEMCP should be there too (if it was
> correctly guessed). Maybe there could be some other corner ca
On Sunday 26 January 2025 19:06:59 Lasse Collin wrote:
> On 2025-01-25 Pali Rohár wrote:
> > On Saturday 25 January 2025 18:52:26 Lasse Collin wrote:
> > > Even if wide char functions were always used to read filenames,
> > > perhaps AreFileApisANSI() needs to be taken into account in
> > > readdir
On 2025-01-25 Pali Rohár wrote:
> On Saturday 25 January 2025 18:52:26 Lasse Collin wrote:
> > Even if wide char functions were always used to read filenames,
> > perhaps AreFileApisANSI() needs to be taken into account in
> > readdir() to determine if the wide char names should be converted
> > to
On Saturday 25 January 2025 18:52:26 Lasse Collin wrote:
> On 2025-01-25 Lasse Collin wrote:
> > On 2025-01-25 Pali Rohár wrote:
> > > Also what could be different is that _findfirst may be affected by
> > > setlocale function as IIRC UCRT supports changing process locale but
> > > only for UCRT fu
On 2025-01-25 Lasse Collin wrote:
> On 2025-01-25 Pali Rohár wrote:
> > Also what could be different is that _findfirst may be affected by
> > setlocale function as IIRC UCRT supports changing process locale but
> > only for UCRT functions.
> >
> > Another important thing is that FindFirstFile is
On 2025-01-25 Pali Rohár wrote:
> On Saturday 25 January 2025 12:39:19 Lasse Collin wrote:
> > The CRT functions prodide timestamps in time_t while Win32 API
> > provides FILETIME. Perhaps the conversion wastes time. The dirent
> > functions don't need file timestamps.
>
> Maybe that time conver
On Saturday 25 January 2025 12:39:19 Lasse Collin wrote:
> On 2025-01-17 Pali Rohár wrote:
> > On Friday 17 January 2025 15:22:30 Lasse Collin wrote:
> > > Another possible change could be to call FindFirstFileW directly
> > > instead of going via _wfindfirst.
> >
> > Personally I would prefer t
On 2025-01-17 Pali Rohár wrote:
> On Friday 17 January 2025 15:22:30 Lasse Collin wrote:
> > Another possible change could be to call FindFirstFileW directly
> > instead of going via _wfindfirst.
>
> Personally I would prefer to stay with _wfindfirst as it is from
> MS C runtime library.
Callin
39 matches
Mail list logo
