lstat symbolic link size

Brian Ford
Wed Jan 7 17:33:00 GMT 2004

On Mon, 5 Jan 2004, Christopher Faylor wrote:

> On Mon, Jan 05, 2004 at 08:38:24PM -0500, Christopher Faylor wrote:
> >On Tue, Jan 06, 2004 at 09:30:26AM +0800, peter garrone wrote:
> >>lstat returns an incorrect symbolic link size, with size 11 bytes too large.
> >>
> >lstat reports the actual size of the symlink file.  Unless you can point
> >to a standard which indicates this is incorrect, we'll be sticking with
> >this long standing behavior.
> >
> Actually, nevermind.  SUSv3 says this:
> For symbolic links, the st_mode member shall contain meaningful
> information when used with the file type macros, and the st_size member
> shall contain the length of the pathname contained in the symbolic link.
> So, this is a PTC situation.
Ok, here it is.

2004-01-07  Brian Ford  <>

	* (fhandler_base::fstat_helper): Comply with
	SUSv3 for a symlink's st_size, ie. the length of the target

Note that this is untested as current CVS suffers from a problem similar
to the last one reported here:

Details in case they are usefull:

$ env PATH="../../cygwin:${PATH}" gdb ./checksignal.exe
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program: /home/ford/downloads/cygb2/i686-pc-cygwin/winsup/testsuite/testsuite/checksignal.exe

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 364.0x152]
0x00aee654 in ?? ()
(gdb) bt
#0  0x00aee654 in ?? ()
#1  0x610041b8 in _threadinfo::call(unsigned long (*)(void*, void*), void*) (
    func=0xaee650, arg=0xaee414)
    at ../../../../cygwin/winsup/cygwin/
#2  0x610041b8 in _threadinfo::call(unsigned long (*)(void*, void*), void*) (
    func=0xaee650, arg=0xaee414)
    at ../../../../cygwin/winsup/cygwin/
(gdb) info threads
* 2 thread 364.0x152  0x00aee654 in ?? ()
  1 thread 364.0x1a5  _mbtowc_r (r=0x22e650, pwc=0x22e1d8,
    s=0x6101df41 "cYgstd %x %x %x", n=2286176, state=0x22e278)
    at ../../../../../cygwin/newlib/libc/stdlib/mbtowc_r.c:56
(gdb) thread 1
[Switching to thread 1 (thread 364.0x1a5)]#0  _mbtowc_r (r=0x22e650,
    pwc=0x22e1d8, s=0x6101df41 "cYgstd %x %x %x", n=2286176, state=0x22e278)
    at ../../../../../cygwin/newlib/libc/stdlib/mbtowc_r.c:56
56      {
(gdb) bt
#0  _mbtowc_r (r=0x22e650, pwc=0x22e1d8, s=0x6101df41 "cYgstd %x %x %x",
    n=2286176, state=0x22e278)
    at ../../../../../cygwin/newlib/libc/stdlib/mbtowc_r.c:56
#1  0x610dac61 in sprintf (str=0x22e278 "+", fmt=0x6101df41 "cYgstd %x %x %x")
    at ../../../../../cygwin/newlib/libc/stdio/sprintf.c:373
#2  0x6101dfc0 in dtable::get_debugger_info() (this=0x6167018c)
    at ../../../../cygwin/winsup/cygwin/
#3  0x610ab562 in tty_init() () at ../../../../cygwin/winsup/cygwin/
#4  0x610056ab in dll_crt0_1(char*) ()
    at ../../../../cygwin/winsup/cygwin/
#5  0x6100616a in _dll_crt0 () at ../../../../cygwin/winsup/cygwin/
(gdb) q

Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444
-------------- next part --------------
RCS file: /cvs/src/src/winsup/cygwin/,v
retrieving revision 1.75
diff -u -p -r1.75
---	15 Dec 2003 04:16:42 -0000	1.75
+++	7 Jan 2004 17:23:10 -0000
@@ -291,6 +291,8 @@ fhandler_base::fstat_helper (struct __st
       /* symlinks are everything for everyone! */
       buf->st_mode = S_IFLNK | S_IRWXU | S_IRWXG | S_IRWXO;
+      /* SUSv3: their size is the length of the target pathname */
+      buf->st_size = strlen (pc.get_win32 ());
       get_file_attribute (pc.has_acls (), get_win32_name (), NULL,
 			  &buf->st_uid, &buf->st_gid);
       goto done;

More information about the Cygwin-patches mailing list