8 [main] stat-size-test 3620 dtable::delete_archetype: deleting
element 0 for /dev/pty0(136/0)
306 113984 [main] stat-size-test 3620 getpid: 3620 = getpid()
201 114185 [main] stat-size-test 3620 proc_terminate: nprocs 0
307 114492 [main] stat-size-test 3620 proc_terminate: leaving
357 1148
On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com"
saying:
> On Nov 2 08:08, Jonathan Lennox wrote:
> > On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com"
> > saying:
> >
> &
On Monday, November 2 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com"
saying:
> On Nov 2 04:38, Jonathan Lennox wrote:
> > Unfortunately, when I do "Run As Administrator" on MinTTY, the Mac drives
> > (/cygdrive/z and /cygdrive/y) don't
On Wednesday, October 21 2015, "Corinna Vinschen" wrote to "cygwin@cygwin.com"
saying:
> On Oct 8 12:16, Jonathan Lennox wrote:
> > Hi, following up on this issue from last year. The message I'm replying to
> > is at <https://cygwin.com/ml/cygwin/2014
use the
> FileId as inode number on filesystems with FILE_PERSISTENT_ACLS==FALSE
> so, never mind.
>
> OTOH, does it support hardlinks? If so, two hardlinks to the
> same file would have different inode numbers on Cygwin.
How would I figure these points out?
--
Jonathan
kier, since you'd want to keep compatibility with
filenames containing tildes on existing managed mounts.
--
Jonathan Lennox
lennox at cs dot columbia dot edu
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentat
On Tuesday, February 20 2007, "Eric Blake" wrote to "Jonathan Lennox,
cygwin@cygwin.com" saying:
> > Cygwin managed mounts give surprising (to me) results if a filename that's
> > not in its canonical form manages to get below the managed mountpoint:
&g
id Win32 name for the file. (I
haven't been able to construct any other Win32 filenames that don't map to a
valid managed-POSIX filename.)
Is there a downside to this, other than an extra call to cyg_tolower in
fnunmunge?
--
Jonathan Lennox
lennox at cs dot columbia dot edu
--
Uns
printf(" addr=%s",
inet_ntoa(((struct
sockaddr_in*)(&ifr->ifr_addr))->sin_addr));
break;
default:
printf(" [AF Unsupported]");
break;
printf(" addr=%s",
inet_ntoa(((struct
sockaddr_in*)(&ifr->ifr_addr))->sin_addr));
break;
default:
printf(" [AF Unsupported]");
break;
ects from random stack or
heap garbage? In particular, it seems like this is an area where an
attacker could potentially cause odd effects by causing the pthread objects'
magic numbers to be written to the stack or heap in memory that is
subsequently re-used.
--
Jonathan Lennox
lennox at cs dot
11 matches
Mail list logo
