RE: New snapshot with significant new functionality

RE: New snapshot with significant new functionality

[Robert Collins]

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu] 
> Sent: Friday, May 03, 2002 1:46 PM

> That might work --- but I'd make it auto-reset after every 
> atomic write. 
>   So, you have to say
>    $ cat '1' > /proc/registry/.writeable
> 
>   $ <access one single "file" in the registry>
> 
>    $ cat /proc/registry/.writable
>    0

Two things: if /proc/registry isn't writable, cating 1 to
/proc/registry/.writeable won't work - without special case code. I'd
suggest /proc/sysopts/fs/registry/writeable.

Two, why not have two options:
writeable
nextwrite

one is persistent (until all cygwin processes end). The other is for a
single transaction.

Rob

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Charles Wilson]

Robert Collins wrote:


> Two things: if /proc/registry isn't writable, cating 1 to
> /proc/registry/.writeable won't work - without special case code. I'd
> suggest /proc/sysopts/fs/registry/writeable.
> 
> Two, why not have two options:
> writeable
> nextwrite
> 
> one is persistent (until all cygwin processes end). The other is for a
> single transaction.


Because I don't want to make it easy.  Besides, if you really want 
"persistence", here's how to shoot yourself in the foot (or head):

-------
#!/bin/sh
echo '1' > /proc/sysopts/fs/registry/writeable
$*

-------


--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: New snapshot with significant new functionality

[Chris Metcalf]

On Fri, 3 May 2002, Robert Collins wrote:
> Two things: if /proc/registry isn't writable, cating 1 to
> /proc/registry/.writeable won't work - without special case code. I'd
> suggest /proc/sysopts/fs/registry/writeable.
> 
> Two, why not have two options:
> writeable
> nextwrite
> 
> one is persistent (until all cygwin processes end). The other is for a
> single transaction.

The "single transaction" mode seems like it might be race-prone, if two 
processes (or two threads of the same process) are both accessing the 
registry.  Perhaps it would be cleaner to allow a process to open a 
registry file for write, but then require some fd-specific action (e.g. an 
ioctl, or perhaps writing the fd number to a /proc/sysopts file) to enable 
it to *really* work for write.

                Chris Metcalf -- InCert Software -- 1 (617) 621 8080
                metcalf@incert.com -- http://www.incert.com/~metcalf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: New snapshot with significant new functionality

[Randall R Schulz]

Chris, Chris, Chris,

Here are a couple of alternate ideas:

1) Require a mount to access /proc (or just /proc/registry). Use a 
mount-time option to enable writability of the registry portion of /proc 
(an option to the mount command and a bit in the __flags argument to the 
mount system call).

2) Use the writability of /proc/registry. This has the advantage of 
providing some selectivity w.r.t. which user attempts the registry update.


Randall Schulz
Mountain View, CA USA



At 13:14 2002-05-05, you wrote:
>On Fri, 3 May 2002, Robert Collins wrote:
> > Two things: if /proc/registry isn't writable, cating 1 to
> > /proc/registry/.writeable won't work - without special case code. I'd
> > suggest /proc/sysopts/fs/registry/writeable.
> >
> > Two, why not have two options:
> > writeable
> > nextwrite
> >
> > one is persistent (until all cygwin processes end). The other is for a 
> single transaction.
>
>The "single transaction" mode seems like it might be race-prone, if two 
>processes (or two threads of the same process) are both accessing the 
>registry.  Perhaps it would be cleaner to allow a process to open a 
>registry file for write, but then require some fd-specific action (e.g. an 
>ioctl, or perhaps writing the fd number to a /proc/sysopts file) to enable 
>it to *really* work for write.
>
>                 Chris Metcalf -- InCert Software -- 1 (617) 621 8080
>                 metcalf@incert.com -- http://www.incert.com/~metcalf\


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Christopher Faylor]

On Sun, May 05, 2002 at 01:54:37PM -0700, Randall R Schulz wrote:
>Chris, Chris, Chris,
>
>Here are a couple of alternate ideas:
>
>1) Require a mount to access /proc (or just /proc/registry).

From my Thu, 2 May 2002 22:47:31 -0400 mail:
>Long term, this kind of stuff should be somehow "mountable".  Corinna
>and DJ had a plan for doing something like this at one time.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Kiran Prakash]

Just looked at it.
Nice.

Seems to barf on colons in filenames, though, which do occur in the
registry.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[fergus]

No problems, but is all the following expected behaviour? Having
uncompressed the new .dll and copied it to /bin:

1. had to make /proc using mkdir /proc

2. ls -al / doesn't actually show /proc

3. ls -al /proc shows (something like)

dr-xr-xr-x   10 0        medicine        0 Jan  1  1970 1951627
dr-xr-xr-x   10 0        medicine        0 Jan  1  1970 2022611
dr-xr-xr-x    7 0        medicine        0 May  2 07:11 registry
-r--r--r--    1 0        medicine        0 May  2 07:11 uptime
-r--r--r--    1 0        medicine        0 May  2 07:11 version

4. Note lack of . and ..

5. ls -al /proc/1951627 shows a lot of stuff, but

6. ls -al /proc/2022611 gives

ls: /proc/2022611: No such file or directory

If this is all what /should/ happen then that's fine (and please excuse
naive questioning).

Fergus


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Pierre Muller]

At 08:15 02/05/2002 , fergus@bonhard.uklinux.net a écrit:
>No problems, but is all the following expected behaviour? Having
>uncompressed the new .dll and copied it to /bin:
>
>1. had to make /proc using mkdir /proc
>
>2. ls -al / doesn't actually show /proc
>
>3. ls -al /proc shows (something like)
>
>dr-xr-xr-x   10 0        medicine        0 Jan  1  1970 1951627
>dr-xr-xr-x   10 0        medicine        0 Jan  1  1970 2022611
>dr-xr-xr-x    7 0        medicine        0 May  2 07:11 registry
>-r--r--r--    1 0        medicine        0 May  2 07:11 uptime
>-r--r--r--    1 0        medicine        0 May  2 07:11 version
>
>4. Note lack of . and ..
>
>5. ls -al /proc/1951627 shows a lot of stuff, but
>
>6. ls -al /proc/2022611 gives
>ls: /proc/2022611: No such file or directory

This is probably just because
that one is the entry for the 'ls -al /proc' itself,
and thus is invalid after end of execution of 'ls -al /proc'.



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Chris January]

> >No problems, but is all the following expected behaviour? Having
> >uncompressed the new .dll and copied it to /bin:
> >
> >1. had to make /proc using mkdir /proc

Yes, same way you have to mkdir /cygdrive if you want it to show up in a
directory listing I'm afraid.

> >
> >2. ls -al / doesn't actually show /proc
> >
> >3. ls -al /proc shows (something like)
> >
> >dr-xr-xr-x   10 0        medicine        0 Jan  1  1970 1951627
> >dr-xr-xr-x   10 0        medicine        0 Jan  1  1970 2022611
> >dr-xr-xr-x    7 0        medicine        0 May  2 07:11 registry
> >-r--r--r--    1 0        medicine        0 May  2 07:11 uptime
> >-r--r--r--    1 0        medicine        0 May  2 07:11 version
Hmm - maybe the process date/times could be set to when the process was
created.

> >
> >4. Note lack of . and ..
That's a bug.

> >
> >5. ls -al /proc/1951627 shows a lot of stuff, but
> >
> >6. ls -al /proc/2022611 gives
> >ls: /proc/2022611: No such file or directory

This is because process 2022611 is the process number of ls /proc, which has
gone away by the time you do the next ls.

There are a few other bugs that I'm aware of:
i) cat /proc/<dir> gives "File exists" instead of "Is a directory" error.
ii) cat /proc/nofile gives "No such file or directory" error (correct), but
cat /proc/<pid>/nofile gives "Read only file system" error.
iii) cp <file> /proc/nofile gives "No such file or directory" instead of
"Permission denied" or "Read only file system" error.

I'll try to fix these as and when I have the time.

Regards
Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Dr. Volker Zell]

Hi

Cool feature.


08:31am [507]> cat /proc/uptime 
3728.83
08:31am [506]> cat < /proc/uptime 

Boom, cat stack dumbs.

Ciao
  Volker


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Chris January]

> Hi
>
> Cool feature.
>
>
> 08:31am [507]> cat /proc/uptime
> 3728.83
> 08:31am [506]> cat < /proc/uptime
>
> Boom, cat stack dumbs.
Chris' implementation of dup() in fhander_virtual is broken, so things like
fork(), etc. won't work.

Regards
Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Chris January]

> > Hi
> >
> > Cool feature.
> >
> >
> > 08:31am [507]> cat /proc/uptime
> > 3728.83
> > 08:31am [506]> cat < /proc/uptime
> >
> > Boom, cat stack dumbs.
> Chris' implementation of dup() in fhander_virtual is broken, so things
like
> fork(), etc. won't work.
That should read: "My implementation..." dup() was broken in the original
patch.

Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

New snapshot with significant new functionality

[Christopher Faylor]

A couple of months ago Chris January submitted some significant new
functionality to cygwin which I've finally gotten around to merging
into the current cygwin sources.

His changes add a /proc filesystem to cygwin.  You can see what it does
by downloading the latest bzip2'ed dll from http://cygwin.com/snapshots/,
uncompressing it somewhere, stopping all cygwin processes, and then
moving the uncompressed cygwin1.dll into c:\cygwin\bin (or whereever)
using the windows COPY command.  You can't use cygwin commands to
overwrite the cygwin DLL, for hopefully obvious reasons.

(And, no, I have no interest in adding snapshot installation abilities
to setup.exe.  Thanks for coming up with this radical new idea, though.)

Once you've done all that you'll be able to amaze yourself by typing:

    ls /proc
or
    ls /proc/registry

Chris has said that he has no time to support this new functionality
but I thought it was cool enough to put in anyway.  I'll try to fix
any reported problems.

If you do have problems, report them *here*.  Don't send me private
email.  Don't send email to ChrisJ.  Don't send mail to cygwin-apps,
cygwin-announce, or cygwin-developers (unless you actually are
subscribed and want to talk about the implementation).  If you think the
code should be patched, don't send mail to cygwin-patches unless you
actually have a patch to submit.

Have fun.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Gerrit P. Haase]

Christopher schrieb:

[...]

> Once you've done all that you'll be able to amaze yourself by typing:

>     ls /proc
> or
>     ls /proc/registry

[...]

> Have fun.

Yes, that is fantastic;)

$ ls /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/GNU/XMail/
MAIL_ROOT

$ ls /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/GNU/XMail/MAIL_ROOT
/proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/GNU/XMail/MAIL_ROOT

$ cat /proc/registry/HKEY_LOCAL_MACHINE/SOFTWARE/GNU/XMail/MAIL_ROOT
I:\


Wow.


Gerrit
-- 
=^..^=


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Randall R Schulz]

Chris & Chris,

Cool!

Is the registry as reflected in /proc/registry writable?

Randall Schulz
Mountain View, CA USA


At 21:58 2002-05-01, you wrote:
>A couple of months ago Chris January submitted some significant new 
>functionality to cygwin which I've finally gotten around to merging into 
>the current cygwin sources.
>
>His changes add a /proc filesystem to cygwin...
>
>...
>
>Once you've done all that you'll be able to amaze yourself by typing:
>
>     ls /proc
>or
>     ls /proc/registry
>
>...
>
>cgf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Chris January]

> Chris & Chris,
>
> Cool!
>
> Is the registry as reflected in /proc/registry writable?
I'm torn between writing "no", and "no, not yet".
The problem with this is that it is inevitable that at some point or other
someone will post to the cygwin mailing list complaining they typed rm -rf
/proc/registry/* and now their system is hosed and it's all Red Hat's
fault...
Certainly there would have to be some kind of 'safety' mechanism, whereby by
default /proc/registry was read-only, but somehow it could be made writable,
perhaps by writing '1' to /proc/registry/.writable or something.

Regards
Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Christopher Faylor]

On Fri, May 03, 2002 at 01:14:52AM +0100, Chris January wrote:
>> Chris & Chris,
>>
>> Cool!
>>
>> Is the registry as reflected in /proc/registry writable?
>I'm torn between writing "no", and "no, not yet".
>The problem with this is that it is inevitable that at some point or other
>someone will post to the cygwin mailing list complaining they typed rm -rf
>/proc/registry/* and now their system is hosed and it's all Red Hat's
>fault...

Yeah, I'd be waiting for that.

Right now, I'm waiting for the first "I upgraded cygwin and now my /proc
directory has strange stuff in it!" message.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Larry Hall (RFK Partners, Inc)]

At 08:30 PM 5/2/2002, you wrote:
>On Fri, May 03, 2002 at 01:14:52AM +0100, Chris January wrote:
> >> Chris & Chris,
> >>
> >> Cool!
> >>
> >> Is the registry as reflected in /proc/registry writable?
> >I'm torn between writing "no", and "no, not yet".
> >The problem with this is that it is inevitable that at some point or other
> >someone will post to the cygwin mailing list complaining they typed rm -rf
> >/proc/registry/* and now their system is hosed and it's all Red Hat's
> >fault...
>
>Yeah, I'd be waiting for that.
>
>Right now, I'm waiting for the first "I upgraded cygwin and now my /proc
>directory has strange stuff in it!" message.



How'd you know that's what I see now?  You're psychic!  Oh and since I found
all this stuff in /proc, I did do a 'rm -rf' on it but it didn't work.  
Please fix this real soon!  I want all this disk space back!!  ;-) ;-) ;-)


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
838 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Charles Wilson]

Chris January wrote:

>>Chris & Chris,
>>
>>Cool!
>>
>>Is the registry as reflected in /proc/registry writable?
>>
> I'm torn between writing "no", and "no, not yet".
> The problem with this is that it is inevitable that at some point or other
> someone will post to the cygwin mailing list complaining they typed rm -rf
> /proc/registry/* and now their system is hosed and it's all Red Hat's
> fault...
> Certainly there would have to be some kind of 'safety' mechanism, whereby by
> default /proc/registry was read-only, but somehow it could be made writable,
> perhaps by writing '1' to /proc/registry/.writable or something.


That might work --- but I'd make it auto-reset after every atomic write. 
  So, you have to say
   $ cat '1' > /proc/registry/.writeable

  $ <access one single "file" in the registry>

   $ cat /proc/registry/.writable
   0

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Chris January]

> If you do have problems, report them *here*.  Don't send me private
> email.  Don't send email to ChrisJ.  Don't send mail to cygwin-apps,
> cygwin-announce, or cygwin-developers (unless you actually are
> subscribed and want to talk about the implementation).  If you think the
> code should be patched, don't send mail to cygwin-patches unless you
> actually have a patch to submit.
Chris, I see you have made the fhandler_virtual, etc. functions use vanilla
path_conv instead of normalized_path or whatever I called it originally.
This relies on path_conv::check returning the normalised posix path instead
of the native path as it usually does. However this breaks stuff like mkdir
/proc badly (in this case, a directory called 'proc' gets created in the
root of C:\). The fix is to go back to using the normalised path explicitly
(i.e. replacing pc with pc.normalized_path) in fhandler_virtual.cc, etc. and
removing the strcpy (path, path_copy) line from path.cc.
Since I have some free time tommorrow I will try to make a patch for this
and some of the other outstanding bugs I know about.
I also need an opinion on how the directory /proc should be treated.
Either:
    i) a real directory called /proc hides the virtual directory /proc
completely
    ii) the virtual directory /proc hides the real directory /proc
completely (other than showing up in a directory listing of /)
    iii) the virtual directory /proc inherits the permissions and ownership
of the real directory /proc if it exists
    iv) the virtual directory /proc is only accessible if there exists a
real directory /proc (combined with one of the above)

Regards
Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Christopher Faylor]

On Fri, May 03, 2002 at 03:16:43AM +0100, Chris January wrote:
>I see you have made the fhandler_virtual, etc.  functions use vanilla
>path_conv instead of normalized_path or whatever I called it
>originally.

Yes.  This is consistent with all of the other fhandler functions.

>This relies on path_conv::check returning the normalised posix path instead
>of the native path as it usually does. However this breaks stuff like mkdir
>/proc badly (in this case, a directory called 'proc' gets created in the
>root of C:\). The fix is to go back to using the normalised path explicitly
>(i.e. replacing pc with pc.normalized_path) in fhandler_virtual.cc, etc. and
>removing the strcpy (path, path_copy) line from path.cc.

The real fix is to use the get_name () method, which I'd started doing
when I realized that I'd reinvented the wheel in consolidating your
patch.  That seems to work fine.  I've finished converting everything (I
hope) to get_name() and checked things in.

I removed my strcpy kludge.

>I also need an opinion on how the directory /proc should be treated.
>Either:
>    i) a real directory called /proc hides the virtual directory /proc
>completely
>    ii) the virtual directory /proc hides the real directory /proc
>completely (other than showing up in a directory listing of /)
>    iii) the virtual directory /proc inherits the permissions and ownership
>of the real directory /proc if it exists
>    iv) the virtual directory /proc is only accessible if there exists a
>real directory /proc (combined with one of the above)

For now, I'd say that it should work just like /cygdrive.  You can
create it but ls /proc still shows the contents of the special directory
not an empty directory.  That's what I've implemented.  Removing your
zeroing of the buffer allowed that, just like it does for the cygdrive
case.

Long term, this kind of stuff should be somehow "mountable".  Corinna and
DJ had a plan for doing something like this at one time.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: New snapshot with significant new functionality

[Chris January]

> >I see you have made the fhandler_virtual, etc.  functions use vanilla
> >path_conv instead of normalized_path or whatever I called it
> >originally.
>
> Yes.  This is consistent with all of the other fhandler functions.
>
> >This relies on path_conv::check returning the normalised posix path
instead
> >of the native path as it usually does. However this breaks stuff like
mkdir
> >/proc badly (in this case, a directory called 'proc' gets created in the
> >root of C:\). The fix is to go back to using the normalised path
explicitly
> >(i.e. replacing pc with pc.normalized_path) in fhandler_virtual.cc, etc.
and
> >removing the strcpy (path, path_copy) line from path.cc.
>
> The real fix is to use the get_name () method, which I'd started doing
> when I realized that I'd reinvented the wheel in consolidating your
> patch.  That seems to work fine.  I've finished converting everything (I
> hope) to get_name() and checked things in.
>
> I removed my strcpy kludge.
>
> >I also need an opinion on how the directory /proc should be treated.
> >Either:
> >    i) a real directory called /proc hides the virtual directory /proc
> >completely
> >    ii) the virtual directory /proc hides the real directory /proc
> >completely (other than showing up in a directory listing of /)
> >    iii) the virtual directory /proc inherits the permissions and
ownership
> >of the real directory /proc if it exists
> >    iv) the virtual directory /proc is only accessible if there exists a
> >real directory /proc (combined with one of the above)
>
> For now, I'd say that it should work just like /cygdrive.  You can
> create it but ls /proc still shows the contents of the special directory
> not an empty directory.  That's what I've implemented.  Removing your
> zeroing of the buffer allowed that, just like it does for the cygdrive
> case.
However it is my opinion that the directory /proc should inherit the
permissions of the real directory if it exists. i.e. ls -ld /proc shows the
real directory's permissions.  This is consistent with the semantics of file
system mounting on Unices. However since the permissions aren't checked at
the moment, this is purely academic.

Chris



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/