On Windows, std::filesystem::symlink_status and is_symlink report a directory symbolic link as a plain directory, so rmdir removed the link instead of failing with ENOTDIR (20) and unlink failed with EPERM (1) instead of removing it, unlike FreeBSD. Detect the symlink reparse tag with FindFirstFileW: rmdir returns ENOTDIR, unlink removes the link with RemoveDirectoryW. Junctions and volume mounts keep their previous behaviour. Enable the directory-link and dangling-link blocks of guest_filesystem on Windows (created with CreateSymbolicLinkW).
AI-assisted: yes
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01GtXavMkgCTCdmRpweviHcQ
sceKernelRmdir decided whether the last component was a symbolic link with
std::filesystem::is_symlink, which follows the link with WinLibs libstdc++ on
Windows. A dangling or self-referencing file link then looked missing on
Windows 10 (ENOENT instead of ENOTDIR), and a directory link to an empty
directory looked like that directory, so rmdir removed the link and
returned 0. The last component is now classified with FillLinkStat, the
same lstat path lstat_nid_postfix uses, matching FreeBSD 11 kern_rmdirat,
which returns ENOTDIR for any non-directory vnode found without following
the last link.
Fixes#12079
Co-Authored-By: Claude Opus 5.5 <[email protected]>
rename looked up its source and destination with
std::filesystem::symlink_status, which MinGW's libstdc++ answers by
following the link, so a dangling or looping link counted as missing
and rename failed with ENOENT. FreeBSD renames the link itself. A path
whose own attributes are a reparse point is now treated as a symbolic
link when symlink_status reports it missing.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
NativeLseek seeked first and only checked for a pipe when the host seek
succeeded, so a negative offset reached the guest as EINVAL from
_lseeki64. FreeBSD 11.4's kern_lseek returns ESPIPE for any seek on a
descriptor without DFLAG_SEEKABLE, so the pipe check now comes first.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Match the AT_REMOVEDIR and rmdir sites so file reparse points stay on the old unlink path. Cover file symlink unlinkat on Windows and point the debt at the drive-target consumers.
rmdir followed the junction and reported ENOTEMPTY, and unlink treated it as a real directory, so a junction to a non-empty folder could not be removed.
std::filesystem::status does not follow a Windows symbolic link under
MinGW, so the lookup chflags makes saw a link whose target is missing as
an existing file and returned 0. A reparse point in the last component
is now looked up through the target with the guest stat, as FreeBSD 11.4's
namei follows it: a missing target gives ENOENT, and a trailing slash
after a link to a file gives ENOTDIR.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Main's #9618 has lstat fill a local FileStat and copy it out to the guest.
The merge keeps that and this branch's module lookup in the same call, so an
original .prx name still resolves to its relinked .guest.prx.
On Windows, rename converted ENOENT or ENOTDIR to ELOOP when either parent directory was below a symbolic link loop. A missing source, or a source below a non-directory, paired with a destination through a loop then reported ELOOP. FreeBSD 11.4 kern_renameat returns the failed source lookup before it examines the destination. A loop below the source still gives ELOOP, and a loop below the destination gives ELOOP only when the source lookup succeeded.
guest_filesystem gains the missing-source and non-directory-source-prefix cases paired with a looping destination, for rename and sceKernelRename.
FreeBSD 11.4's vn_open_cred does not follow the last component when
O_EXCL is set, so O_CREAT|O_EXCL on a symbolic link fails with EEXIST
whatever it points to. On Windows the host open followed a dangling link
and created its target. A reparse point in the last component now fails
O_CREAT|O_EXCL with EEXIST before the host open.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
_wchmod changes the read-only attribute of the path it is given, so on
Windows chmod through a symbolic link changed the link and left the file
it names unchanged, and a dangling link succeeded. A reparse point is now
opened through its target and the target's path is changed, as FreeBSD
11.4's sys_chmod passes FOLLOW: a missing target fails with ENOENT and a
link loop with ELOOP. The path lookup of a handle moves out of
WindowsDescriptorPath_nid_no_patch so both use it.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
FreeBSD resolves the descriptor with getvnode in sys_fchflags
(vfs_syscalls.c:2403), which fails with EINVAL for a descriptor that has no
vnode. fchflags threw for a kqueue descriptor instead.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
FreeBSD 11.4's lookup() (sys/kern/vfs_lookup.c) fails with ENOTDIR when
a path with a trailing slash ends at something that is not a directory.
On Windows a mount alias dropped the slash, and the host calls do not
report ENOTDIR for "file\", so unlink, rename and open acted on the file
or failed with EINVAL. Guest path resolution now rejects an existing
non-directory named with a trailing slash with ENOTDIR on every host, and
a mount alias keeps the slash on Windows as it does on Linux and macOS.
fchmod and sceKernelFchmod on either end of a pipe answered ENOENT on
Windows, where the pipe has no path, and changed the pipe's mode on Linux.
FreeBSD 11's pipe_chmod sends an unnamed pipe to invfo_chmod, which
returns EINVAL, as sockets already get here.
FreeBSD 11.4's vn_seek fails SEEK_CUR and SEEK_END with EOVERFLOW when the base offset plus a positive offset does not fit in an off_t, and with EINVAL only when the result is negative. The host lseek reports EINVAL for the overflow, so the guest saw EINVAL. When the host call fails with EINVAL for a positive offset on SEEK_CUR or SEEK_END, the base position is read back and the call fails with EOVERFLOW if the sum would overflow; the file position is left unchanged.
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
FreeBSD 11 fopen opens the path with _open, and vn_open_vnode refuses a
directory only for FWRITE or O_TRUNC, so fopen of a directory in a read
mode succeeds; Linux hosts already open it. On Windows CreateFileW
without FILE_FLAG_BACKUP_SEMANTICS refused it with EACCES.
fopen now opens such a path as a libkernel directory descriptor, which
libkernel registers in libc when it loads, and fclose and freopen remove
it from libkernel's table. Reads on the stream fail with EISDIR and set
the error indicator, as on a Linux host and FreeBSD's tmpfs: the Windows
CRT fails them already but reports EINVAL. Writes fail with EBADF, and
fseek, ftell and ungetc work, as on any read-only stream.
The two Windows cases, a doubled separator after the drive root and after a
folder name, come from MarcZX10's follow-up d68de63527 to the root review on
this PR.
Co-Authored-By: MarcZX10 <[email protected]>
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Dean