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 should
> > become something else than EIO. I guess it doesn't really matter.
>
> Hard to guess. I think that EIO is enough. POSIX errno codes are not
> prepared for all these Windows stuffs.
>
> > Trying //./PHYSICALDRIVE0 results in EIO and ERROR_GEN_FAILURE
> > (31).
>
> WinAPI path //./PHYSICALDRIVE0 is NT path \??\PhysicalDrive0 which
> is symlink to \Device\Harddisk0\DR0. And this DR0 should represent the
> equivalent of the block device.
>
> For complete information, the \Device\Harddisk0\Partition0 also
> symlink to \Device\Harddisk0\DR0
>
> > In this case ENOTDIR would be better, but I have no idea if that
> > error is possible in some very different situation too. May the
> > exact errno doesn't matter too much with paths like this, and EIO
> > is OK enough.
>
> ERROR_GEN_FAILURE is generic error code which can happen for lot of
> other cases. So EIO is the best translation.
OK, thanks. It helps that this kind of paths won't be passed to opendir
often.
> For having better error code, it would be needed to get the NT status
> code from the syscall, but I'm not sure if it is possible to easily
> get it for FindFirstFileW() function.
Even if it was easy, it might not be worth it in this specific case.
> > Now I noticed that "con" results in EIO and ERROR_NOT_FOUND (1168).
> > I will add it to the list of errors that become ENOTDIR. The old
> > dirent correctly uses ENOTDIR with "con".
>
> Ok, that seems find.
>
> This is interesting error. Different from ERROR_FILE_NOT_FOUND (2) and
> ERROR_PATH_NOT_FOUND (3).
I spotted one more thing: passing \\* to FindFirstFileW fails with
ERROR_BAD_PATHNAME, so I added that to the ENOENT list. The old dirent
uses ENOENT for this too.
It wouldn't surprise me if there were more error codes that are
possible in weird situations. The old dirent uses GetFileAttributes
which catches quite a few weird strings, but it also rejects paths like
\\?\GLOBALROOT\Device\Harddisk0\Partition1.
If all error codes that mean a real I/O error were known for sure, then
it could be an alternative to handle those to set EIO. Then use
something else for unknown errors (maybe EINVAL or ENOENT). This
doesn't feel very important though.
> > > I do not have any other comments for this. Looks good for me.
> >
> > Thanks! May I add you to the commit message with Reviewed-by? Would
> > you like to be included in the credits in dirent.c? Your feedback
> > made get_d_type() better and helped me spot the need for
> > get_code_page().
>
> You can, that is fine.
Thanks!
I attached the (hopefully) final modifications. I will send the
complete patches to the list this week and Cc you.
--
Lasse Collin
From 59a654045a1f87eff9d5d5ae8c6b757cf7980ffd Mon Sep 17 00:00:00 2001
From: Lasse Collin <lasse.col...@tukaani.org>
Date: Wed, 19 Feb 2025 16:19:13 +0200
Subject: [PATCH 10/10] ... Handle two more FindFirstFileW error codes
---
mingw-w64-crt/misc/dirent.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-crt/misc/dirent.c b/mingw-w64-crt/misc/dirent.c
index 90b5d2b08..3faca481b 100644
--- a/mingw-w64-crt/misc/dirent.c
+++ b/mingw-w64-crt/misc/dirent.c
@@ -12,7 +12,8 @@
* Significantly revised and rewinddir, seekdir and telldir added by Colin
* Peters <co...@fu.is.saga-u.ac.jp>
*
- * Revised by Lasse Collin <lasse.col...@tukaani.org> in 2025:
+ * Revised by Lasse Collin <lasse.col...@tukaani.org> and
+ * Pali Rohár <pali.ro...@gmail.com> in 2025:
* - unified DIR and _WDIR
* - long path aware (no MAX_PATH limit)
* - readdir supports long UTF-8 filenames (up to 778 bytes including \0)
@@ -235,6 +236,7 @@ _wopendir (const wchar_t *path)
case ERROR_PATH_NOT_FOUND:
case ERROR_INVALID_NAME:
+ case ERROR_BAD_PATHNAME:
case ERROR_BAD_NETPATH:
case ERROR_BAD_NET_NAME:
/* In addition to the obvious reason, ERROR_PATH_NOT_FOUND
@@ -247,6 +249,8 @@ _wopendir (const wchar_t *path)
* GetFullPathNameW does accept invalid paths so this error is
* indeed possible.
*
+ * ERROR_BAD_PATHNAME occurs if \\* is passed to FindFirstFileW.
+ *
* ERROR_BAD_NETPATH occurs if the server name cannot be resolved
* or if the server doesn't support file sharing.
*
@@ -257,6 +261,7 @@ _wopendir (const wchar_t *path)
case ERROR_DIRECTORY:
case ERROR_INVALID_FUNCTION:
+ case ERROR_NOT_FOUND:
/* Detecting non-directories only works with the last pathname
* component. For example, if there is a file foo, passing
* foo\* to FindFirstFileW will fail with ERROR_DIRECTORY.
@@ -266,7 +271,10 @@ _wopendir (const wchar_t *path)
* ERROR_INVALID_FUNCTION happens at least with the device
* namespace. _wopendir(L"nul") makes GetFullPathNameW produce
* \\.\nul, and then FindFirstFileW is called with \\.\nul\*
- * which results in ERROR_INVALID_FUNCTION. */
+ * which results in ERROR_INVALID_FUNCTION.
+ *
+ * _wopendir(L"con") behaves like nul except that \\.\con\*
+ * results in ERROR_NOT_FOUND */
err = ENOTDIR;
break;
@@ -453,10 +461,12 @@ prepare_next_entry (DIR *dirp)
case ERROR_PATH_NOT_FOUND:
case ERROR_INVALID_NAME:
+ case ERROR_BAD_PATHNAME:
case ERROR_BAD_NETPATH:
case ERROR_BAD_NET_NAME:
case ERROR_DIRECTORY:
case ERROR_INVALID_FUNCTION:
+ case ERROR_NOT_FOUND:
case ERROR_CANT_RESOLVE_FILENAME:
case ERROR_ACCESS_DENIED:
case ERROR_FILENAME_EXCED_RANGE:
--
2.48.1
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
