On Wed, May 18, 2005 at 02:42:12PM -0400, Pierre A. Humblet wrote:
- Original Message -
From: Corinna Vinschen
To: cygwin-patches@cygwin.com
Sent: Wednesday, May 18, 2005 12:48 PM
Subject: Re: [Patch]: mkdir -p and network drives
Hi Pierre,
I don't see a reason why you moved telldir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wrong list. Redirecting.
According to Vance Turner on 5/18/2005 11:06 PM:
I usually don't write you guys, I follow the thread to see how development
is going.
Just a note. The ls command is't quite right.
Ls -lRC wil not recursively list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wrong list. Redirecting.
According to Vance Turner on 5/18/2005 11:06 PM:
I usually don't write you guys, I follow the thread to see how development
is going.
Just a note. The ls command is't quite right.
Ls -lRC wil not recursively list
Here is the implementation of mkdir and rmdir with fhandlers.
To prepare the day where proc_registry will allow writes,
I have removed setting PATH_RO and an error return from path.cc
(it's all handled in the fhandlers).
I have also removed obsolete code about fhandler_cygdrive.
There is another
]
[mailto:[EMAIL PROTECTED] On Behalf Of Pierre A. Humblet
Sent: Wednesday, May 18, 2005 11:42 AM
To: cygwin-patches@cygwin.com
Subject: Re: [Patch]: mkdir -p and network drives
- Original Message -
From: Corinna Vinschen
To: cygwin-patches@cygwin.com
Sent: Wednesday, May 18, 2005 12:48 PM
Additional note
ls -lRC - not working
ls -RCl - working
If you point out the source I will fix it.
On Wed, May 18, 2005 at 10:09:35PM -0700, Vance Turner wrote:
Additional note
ls -lRC - not working
ls -RCl - working
If you point out the source I will fix it.
1) This is not a bug reporting list.
2) This does not, as far as I can tell, have anything to do with the
subject of this message.
On Fri, May 13, 2005 at 02:41:03PM +, Eric Blake wrote:
I added read-only filesystem checking to path_conv::check so the latest
snapshot seems to work fine with the latest coreutils (trixie is a
system in my home network which exports shares):
Almost. With the 20050513 snapshot and
- Original Message -
From: Corinna Vinschen [EMAIL PROTECTED]
To: cygwin-patches@cygwin.com
Sent: Wednesday, May 11, 2005 4:53 AM
Subject: Re: [Patch]: mkdir -p and network drives
I don't like the idea of isrofs being an inline function in dir.cc.
Wouldn't that be better a method
On Thu, May 12, 2005 at 03:49:21PM -0400, Pierre A. Humblet wrote:
- Original Message -
From: Corinna Vinschen [EMAIL PROTECTED]
To: cygwin-patches@cygwin.com
Sent: Wednesday, May 11, 2005 4:53 AM
Subject: Re: [Patch]: mkdir -p and network drives
I don't like the idea of isrofs being
On May 10 20:53, Pierre A. Humblet wrote:
* dir.cc (isrofs): New function.
(mkdir): Check for FH_FS and use isrofs.
(rmdir): Use isrofs.
Index: dir.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dir.cc,v
On Mon, May 09, 2005 at 08:16:36PM -0400, Pierre A. Humblet wrote:
At 06:19 PM 5/9/2005 +, Eric Blake wrote:
Second, the sequence chdir(//), mkdir(machine) creates machine in the
current directory.
Old bug.
chdir(/proc), mkdir(machine) produces the same result.
And mkdir(/proc),
Pierre A. Humblet pierre at phumblet.no-ip.org writes:
Here is a patch to allow mkdir -p to easily work with network
drives and to allow future enumeration of computers and of
network drives by ls -l.
It works by defining a new FH_NETDRIVE virtual handler for
names such as // and
Original Message
From: Eric Blake
Sent: 06 May 2005 23:29
Also, what should //.. resolve to, / or //? And if it resolves to /,
should // be an entry in the readdir() of /? I would argue that //..
should resolve to //, meaning we just have two distinct roots in the
directory tree.
At 06:19 PM 5/9/2005 +, Eric Blake wrote:
Second, the sequence chdir(//), mkdir(machine) creates machine in the
current directory.
Old bug.
chdir(/proc), mkdir(machine) produces the same result.
And mkdir(/proc), mkdir(/proc/machine) creates c:\proc\machine
The fix sets errno to EROFS,
Christopher Faylor [EMAIL PROTECTED] writes:
Except that it can't be made to work correctly due to a bash bug.
Which Bash bug is that? Bash bugs can be fixed.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
On Fri, May 06, 2005 at 11:34:56PM -0700, Paul Eggert wrote:
Christopher Faylor [EMAIL PROTECTED] writes:
Except that it can't be made to work correctly due to a bash bug.
Which Bash bug is that?
Eric Blake alluded to it here:
http://sources.redhat.com/ml/cygwin/2005-05/msg00254.html
Bash is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 5/7/2005 9:43 AM:
Which Bash bug is that?
Bash is the most important program for which 'that chdir(//) is
currently no different from chdir(/)'.
Is that a bug in bash or in cygwin, though? The comments for
On Sat, May 07, 2005 at 11:08:05AM -0600, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 5/7/2005 9:43 AM:
Which Bash bug is that?
Bash is the most important program for which 'that chdir(//) is
currently no different from chdir(/)'.
Is
On Sat, May 07, 2005 at 01:25:40PM -0400, Christopher Faylor wrote:
On Sat, May 07, 2005 at 11:08:05AM -0600, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 5/7/2005 9:43 AM:
Which Bash bug is that?
Bash is the most important program for
cgf wrote:
On Thu, May 05, 2005 at 10:57:08PM -0400, Pierre A. Humblet wrote:
The code should handle // correctly, but path.cc still transforms it
into /, because of the bash bug.
Is that fixed in the current bash?
AFAIK Corinna fixed it once, but the patch got lost and it's currently
not
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
To: cygwin-patches@cygwin.com
Sent: Friday, May 06, 2005 10:22 AM
Subject: Re: [Patch]: mkdir -p and network drives
Well, that was kinda my point. If we can't remove the // handling
because
it breaks bash then adding
On Fri, May 06, 2005 at 10:55:29AM -0400, Pierre A. Humblet wrote:
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
To: cygwin-patches@cygwin.com
Sent: Friday, May 06, 2005 10:22 AM
Subject: Re: [Patch]: mkdir -p and network drives
Well, that was kinda my point. If we
- Original Message -
From: Christopher Faylor [EMAIL PROTECTED]
To: cygwin-patches@cygwin.com
Sent: Friday, May 06, 2005 10:58 AM
Subject: Re: [Patch]: mkdir -p and network drives
On Fri, May 06, 2005 at 10:55:29AM -0400, Pierre A. Humblet wrote:
- Original Message -
From
On Fri, May 06, 2005 at 11:07:13AM -0400, Pierre A. Humblet wrote:
That's not Paul Eggert's position,
http://cygwin.com/ml/cygwin/2005-05/msg00251.html I don't expect
problems with //, we had it working in cvs for a while and only bash
had issues. Program translating // to / should already have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sigh. We need a bash maintainer.
We need to have // working for mkdir -p to work, from what I
understand of the code snippet that was sent to the list.
`mkdir -p' only uses chdir(), mkdir(), and stat() calls. For
//server/share/newdir, the strace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I thought that Eric Blake implied that // *had* to be translated to /,
as per POSIX. I wonder how many programs out there translate a
standalone '//' to '/'.
No, POSIX requires that / be untouched, // be implementation-defined (hint
- - define it
On Fri, May 06, 2005 at 04:29:38PM -0600, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I thought that Eric Blake implied that // *had* to be translated to /,
as per POSIX. I wonder how many programs out there translate a
standalone '//' to '/'.
No, POSIX requires that / be
Igor Pechtchanski [EMAIL PROTECTED] writes:
There's always Pierre's solution of doing minimal support for stat()ing
'//' and '//MACHINE', though...
Yes, that's the basic idea. That's the only thing that makes sense here.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
By the way, the coreutils anon CVS mirror syncronization
appears to be hung again,
I've just sync'd things.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:
On Fri, May 06, 2005 at 11:13:56AM -0700, Paul Eggert wrote:
Igor Pechtchanski [EMAIL PROTECTED] writes:
There's always Pierre's solution of doing minimal support for stat()ing
'//' and '//MACHINE', though...
Yes, that's the basic idea. That's the only thing that makes sense
here.
Except that
On Thu, May 05, 2005 at 10:57:08PM -0400, Pierre A. Humblet wrote:
Here is a patch to allow mkdir -p to easily work with network
drives and to allow future enumeration of computers and of
network drives by ls -l.
It works by defining a new FH_NETDRIVE virtual handler for
names such as // and
Eric Blake [EMAIL PROTECTED] writes:
The only other approach I can think of is to special case leading // (at
least on cygwin, leading // should start after //MACHINE/Share/)
What happens with the file names //, //MACHINE, and
//MACHINE/Share in Cygwin? Don't they appear to be directories,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 5/5/2005 2:09 AM:
What happens with the file names //, //MACHINE, and
//MACHINE/Share in Cygwin? Don't they appear to be directories,
albeit directories that you can't alter? If not, that suggests a bug
in Cygwin.
Eric Blake [EMAIL PROTECTED] writes:
//MACHINE currently generates ENOENT, whether or not there is a
server on the network with that name, and mkdir(2), stat(2), and
chdir(2) with an argument of //MACHINE fail.
That's certainly a hassle. Let's not worry about going through
zillions of lines
On Thu, May 05, 2005 at 09:35:53AM -0700, Paul Eggert wrote:
Eric Blake [EMAIL PROTECTED] writes:
//MACHINE currently generates ENOENT, whether or not there is a
server on the network with that name, and mkdir(2), stat(2), and
chdir(2) with an argument of //MACHINE fail.
That's certainly a
On Thu, 5 May 2005, Paul Eggert wrote:
Eric Blake [EMAIL PROTECTED] writes:
//MACHINE currently generates ENOENT, whether or not there is a
server on the network with that name, and mkdir(2), stat(2), and
chdir(2) with an argument of //MACHINE fail.
That's certainly a hassle. Let's not
Original Message
From: Igor Pechtchanski
Sent: 05 May 2005 18:20
On Thu, 5 May 2005, Paul Eggert wrote:
Eric Blake [EMAIL PROTECTED] writes:
//MACHINE currently generates ENOENT, whether or not there is a
server on the network with that name, and mkdir(2), stat(2), and
chdir(2)
- Original Message -
From: Paul Eggert [EMAIL PROTECTED]
To: Eric Blake [EMAIL PROTECTED]
Cc: Pierre A. Humblet [EMAIL PROTECTED]; cygwin@cygwin.com;
bug-coreutils@gnu.org
Sent: Thursday, May 05, 2005 12:35 PM
Subject: Re: mkdir -p and network drives
Eric Blake [EMAIL PROTECTED
On Thu, May 05, 2005 at 06:44:05PM +0100, Dave Korn wrote:
Original Message
From: Igor Pechtchanski
Sent: 05 May 2005 18:20
On Thu, 5 May 2005, Paul Eggert wrote:
Eric Blake [EMAIL PROTECTED] writes:
//MACHINE currently generates ENOENT, whether or not there is a
server on the
On Thu, 5 May 2005, Dave Korn wrote:
Original Message
From: Igor Pechtchanski
Sent: 05 May 2005 18:20
On Thu, 5 May 2005, Paul Eggert wrote:
Eric Blake [EMAIL PROTECTED] writes:
//MACHINE currently generates ENOENT, whether or not there is a
server on the network with that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 5/5/2005 2:09 AM:
@@ -207,8 +207,14 @@ make_path (const char *argpath,
/* If we've saved the cwd and DIRPATH is an absolute pathname,
we must chdir to `/' in order to enable the chdir optimization.
Eric Blake [EMAIL PROTECTED] writes:
+ if (do_chdir dirpath[0] == '/')
+{
+ /* POSIX says // might be special, so chdir to // if the
+ file name starts with exactly two slashes. */
+ char const *root = // + (dirpath[1] != '/' || dirpath[2] == '/');
Oops -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 5/5/2005 9:47 PM:
Oops - buffer overflow bug. dirpath[2] is past the end of the string on
dirpath of /,
If dirpath is /, then dirpath[1] != '/' is true, so dirpath[2] isn't
evaluated.
Oh well - chalk that one up to me
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pierre A. Humblet on 5/2/2005 9:22 PM:
According to the Cygwin Faq,
*
Why doesn't `mkdir -p' work on a network share?
Unfortunately, you cannot do something like this:
bash$ mkdir -p //MACHINE/Share/path/to/new/dir
On May 3 07:05, Eric Blake wrote:
rather than starting at the left and
making sure each path component exists, the algorithm could start at the
right and successively prune each rightmost component until it no longer
gets ENOENT (or gets to the empty string), then build back up from that
O(n^2)? I see only O(n), regardless where the algorithm begins the search.
In any path of length n, you have a constant sum of n stat and mkdir calls,
AFAICS.
I was using n to mean the number of components separated by /, not the string
length of the path (see the source code
According to the Cygwin Faq,
*
Why doesn't `mkdir -p' work on a network share?
Unfortunately, you cannot do something like this:
bash$ mkdir -p //MACHINE/Share/path/to/new/dir
mkdir: cannot create directory `//MACHINE': No such file or directory
This is because mkdir checks for the
48 matches
Mail list logo
