fstatat of symlink to fifo gets st_mode from symlink, not from fifo
brian.inglis@systematicsw.ab.ca
brian.inglis@systematicsw.ab.ca
Fri Sep 25 08:58:35 GMT 2026
On 2026-09-25 02:22, Jakob Bohm via Cygwin wrote:
> On 25/09/2026 02:26, Mark Geisert via Cygwin wrote:
>> Replying to myself, I write:
>>
>> On 9/12/2026 2:50 AM, Mark Geisert via Cygwin wrote:
>>> Hello raf,
>>>
>>> On 9/6/2026 10:33 PM, raf via Cygwin wrote:
>>>> Hi,
>>>>
>>>> This is on Win10.
>>>>
>>>> I have a seemingly impossible problem with fstatat following a symlink to
>>>> a fifo. Most of the resulting struct stat correctly contains details of the
>>>> fifo except for the st_mode field. It contains the type and permissions
>>>> of the symlink itself.
>>>>
>>>> I assume I must be doing something wrong but the same code works on
>>>> six other operating systems.
>>>>
>>>> Any idea what the cause might be? My tests relating to this have been
>>>> failing for ages, and I just accepted that this wierd little case just
>>>> might not work on Cygwin, but looking into it closely shows that it
>>>> almost does work, just not quite.
>>>>
>>>> Actually, the same problem happens with stat(1), not just my program.
>>>> Here's a demonstration:
>>>>
>>>> mkdir t
>>>> cd t
>>>> mkfifo fifo
>>>> sleep 5
>>>> ln -s fifo symfifo
>>>> stat symfifo fifo
>>>> stat -L symfifo
>>>> cd ..
>>>> rm -r t
>>>>
>>>> The above commands show this ouptut:
>>>>
>>>> $ stat symfifo fifo
>>>> File: symfifo -> fifo
>>>> Size: 4 Blocks: 0 IO Block: 65536 symbolic link
>>>> Device: 15518,20572 Inode: 7599824372130494 Links: 1
>>>> Access: (0777/lrwxrwxrwx) Uid: (197609/ john) Gid: (197121/ None)
>>>> Access: 2026-09-07 15:25:50.209111800 +1000
>>>> Modify: 2026-09-07 15:25:50.209111800 +1000
>>>> Change: 2026-09-07 15:25:50.209111800 +1000
>>>> Birth: 2026-09-07 15:25:50.209111800 +1000
>>>> File: fifo
>>>> Size: 0 Blocks: 1 IO Block: 65536 fifo
>>>> Device: 0,196 Inode: 8162774325551800 Links: 1
>>>> Access: (0666/prw-rw-rw-) Uid: (197609/ john) Gid: (197121/ None)
>>>> Access: 2026-09-07 15:25:49.754243600 +1000
>>>> Modify: 2026-09-07 15:25:43.732451800 +1000
>>>> Change: 2026-09-07 15:25:43.732451800 +1000
>>>> Birth: 2026-09-07 15:25:43.732451800 +1000
>>>> $ stat -L symfifo
>>>> File: symfifo -> fifo
>>>> Size: 4294953488 Blocks: 1 IO Block: 65536 symbolic link
>>>> Device: 0,196 Inode: 8162774325551800 Links: 1
>>>> Access: (0777/lrwxrwxrwx) Uid: (197609/ john) Gid: (197121/ None)
>>>> Access: 2026-09-07 15:25:53.970058800 +1000
>>>> Modify: 2026-09-07 15:25:43.732451800 +1000
>>>> Change: 2026-09-07 15:25:43.732451800 +1000
>>>> Birth: 2026-09-07 15:25:43.732451800 +1000
>>>>
>>>> Note that the last command that follows the symlink
>>>> states that the fifo is a "symbolic link" rather than "fifo"
>>>> and permissions "0777/lrwxrwxrwx" rather than "0666/prw-rw-rw-".
>>>>
>>>> Is this fixable? Or is it just this pc?
>>>
>>> I've reproduced this locally, so it's not your pc ;-). What version of
>>> Cygwin are you running on your Windows 10 machine?
>>>
>>> I've also reproduced this on Cygwin 3.3.6, which is pretty old. You may have
>>> just run into a bug that has gone undiscovered for a long time. I'll look
>>> into investigating and patching this issue.
>>> Thanks for the report,
>>
>> This appears to be due to Cygwin fifos being represented in the Windows
>> filesystem as symlinks. That is, if you list the contents of your 't'
>> directory in a Command Prompt window, you'll see 'fifo.lnk' instead of
>> 'fifo'. So your 'symfifo' turns out to be a symlink to a symlink.
>>
>> I will continue to investigate whether that can be adjusted within Cygwin to
>> match behavior of other Unix derivatives like Linux. This may take a while.
>> Thanks again for the report!
>>
> Note that using "Application icon links" (file extension .LNK), which are
> equivalent to GNOME "desktop files", to represent actual symlinks in some Cygwin
> configurations is problematic in other ways compared to using the actual WinNT
> Symlink mechanisms shared with the POSIX/Interix/Whatever subsystem . There is
> also the Cygwin/Ming32 configuration where a Cygwin symlink is stored as a
> special file with the same and a rare combination of FAT-like attributes, thus
> speeding up checks if a Windows plain file is Cygwin symlink or other special file.
>
> On a more fundamental level, it is a question if a Cygwin FIFO could be
> represented as one of the Win32 special file types from the "named pipe"
> category, either as a symlink to such a pipe or by having a pipe in the other-
> obhect name space have a specilly formatted name that maps 1:1 to the Win32 path
> of the file system location where Cygwin sees the fifo special file. Similarly,
> most Cygwin "device special files" could become symlinks to actual NT namespace
> device files such as L"\Device\HarddiskVolume2" or "\GLOBAL??\NUL" etc. etc. Or
> the Cygwin "/dev/" dir could become entirely synthetic like "/proc/", with "/
> dev/NT/" being an alias for "\Device\" without renames to POSIX traditions.
Check out `/proc/sys/` on your own or work system or CI:
$ l /proc/sys/
ArcName/ MicrosoftMalwareProtectionControlPortWD
BaseNamedObjects/ MicrosoftMalwareProtectionPortWD
BindFltPort MicrosoftMalwareProtectionRemoteIoPortWD
Callback/ MicrosoftMalwareProtectionVeryLowIoPortWD
CLDMSGPORT NLS/
clfs Ntfs
CsrSbSyncEvent ObjectTypes/
Device/ OSDataRoot
Dfs PdcPort
DosDevices/ PendingRenameMutex
Driver/ PowerMonitorPort
DriverData/ PowerPort
DriverStores/ REGISTRY
DSYSDBG.Debug.Trace.Memory.3f4 RPC Control/
EFSInitEvent SAM_SERVICE_STARTED
Fat Security/
FatCdrom SeLsaCommandPort
FileSystem/ SeRmCommandPort
GLOBAL??/ Sessions/
KernelObjects/ SmApiPort
KnownDlls/ SmSsWinStationApiPort
KnownDlls32/ storqosfltport
LanmanServerAnnounceEvent SystemRoot/
LsaPerformance ThemeApiPort
MicrosoftDataLossPreventionAsyncPort UMDFCommunicationPorts/
MicrosoftDataLossPreventionControlPort UniqueInteractiveSessionIdEvent
MicrosoftDataLossPreventionPort WcifsPort
MicrosoftDataLossPreventionRemoteIoPort Win32kCrossSessionGlobals
MicrosoftDataLossPreventionVeryLowIoPort Windows/
MicrosoftMalwareProtectionAsyncPortWD
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
More information about the Cygwin
mailing list