[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify Digest, Vol 54, Issue 2
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2010-11-05 11:54:21
Message-ID: mailman.39481.1288958061.5007.mingw-notify () lists ! sourceforge ! net
[Download RAW message or body]
Send MinGW-notify mailing list submissions to
mingw-notify@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request@lists.sourceforge.net
You can reach the person managing the list at
mingw-notify-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."
This list is used to send updates of submitted patches, bug reports and file \
releases. You are discouraged from posting to this list. If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Today's Topics:
1. [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation (SF/projects/mingw notification list)
2. [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation (SF/projects/mingw notification list)
3. [ mingw-Bugs-3101688 ] can't open files larger than 4GB.
(SF/projects/mingw notification list)
4. [ mingw-Bugs-3101688 ] can't open files larger than 4GB.
(SF/projects/mingw notification list)
5. [ mingw-Bugs-3101688 ] can't open files larger than 4GB.
(SF/projects/mingw notification list)
6. [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation (SF/projects/mingw notification list)
7. [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation (SF/projects/mingw notification list)
----------------------------------------------------------------------
Message: 1
Date: Mon, 01 Nov 2010 15:42:08 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation
To: noreply@sourceforge.net
Message-ID: <E1PCwWO-0003rr-1p@sfs-web-2.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3091216, was opened at 2010-10-20 11:39
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
> Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gwowen ()
> Assigned to: Cesar Strauss (cstrauss)
Summary: mkdir -p fails with //server/dir/subdir notation
Initial Comment:
If you use UNC with forward slashes to designate network address, then mkdir -p won't \
create parents when necessary
$ ls //superserver/data/tmp/foo
ls: //superserver/data/tmp/foo: No such file or directory
$ mkdir //superserver/data/tmp/foo
$ ls //superserver/data/tmp/foo
The directory exists on the network resource, which is as expected...
However if I now do
$ mkdir -p //superserver/data/tmp/foo/bar/baz/shazam
I get no error message, but
$ ls //superserver/data/tmp/foo/bar/baz/shazam
ls: //superserver/data/tmp/foo/bar/baz/shazam: No such file or directory
In fact, the requested directory hierarchy gets made under the root directory, \
exactly as if I had a single leading slash, not a double leading slash...
This is MSYS-1.0.11, mkdir --version says: mkdir (GNU coreutils) 5.97
----------------------------------------------------------------------
> Comment By: Keith Marshall (keithmarshall)
Date: 2010-11-01 15:42
Message:
Confirmed here:
$ uname -a
MINGW32_NT-6.0 ... 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
$ mkdir --version
mkdir (GNU coreutils) 5.97
...
$ ls //domain/data/HoneywellManuals
...
ad20110.pdf ad21110.pdf ad40110.pdf ad41110.pdf
ad80110.pdf ad90110.pdf am03500.pdf am09501.pdf
...
works for me, but:
$ mkdir -p //domain/data/HoneywellManuals/foo/bar
fails silently, (with no evidence of directory creation anywhere, in my
case).
However:
$ mkdir //domain/data/HoneywellManuals/foo
$ mkdir //domain/data/HoneywellManuals/foo/bar
does work as expected, as does:
$ mkdir -p /w/HoneywellManuals/foo/bar
(W: is a mapped network drive, set up by my network/domain administrator,
to represent //domain/data).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
------------------------------
Message: 2
Date: Tue, 02 Nov 2010 12:57:04 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation
To: noreply@sourceforge.net
Message-ID: <E1PDGQC-0004KR-I6@sfs-web-5.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3091216, was opened at 2010-10-20 07:39
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gwowen ()
Assigned to: Cesar Strauss (cstrauss)
Summary: mkdir -p fails with //server/dir/subdir notation
Initial Comment:
If you use UNC with forward slashes to designate network address, then mkdir -p won't \
create parents when necessary
$ ls //superserver/data/tmp/foo
ls: //superserver/data/tmp/foo: No such file or directory
$ mkdir //superserver/data/tmp/foo
$ ls //superserver/data/tmp/foo
The directory exists on the network resource, which is as expected...
However if I now do
$ mkdir -p //superserver/data/tmp/foo/bar/baz/shazam
I get no error message, but
$ ls //superserver/data/tmp/foo/bar/baz/shazam
ls: //superserver/data/tmp/foo/bar/baz/shazam: No such file or directory
In fact, the requested directory hierarchy gets made under the root directory, \
exactly as if I had a single leading slash, not a double leading slash...
This is MSYS-1.0.11, mkdir --version says: mkdir (GNU coreutils) 5.97
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2010-11-02 08:57
Message:
The // becomes / as a feature of MSYS to help with /C style switches in
Windows. To use //domain/some/dir you need to add another / so for MSYS
the proper notation for using domains is ///domain/some/dir since multiple
/ removes one / from the string. In my thinking this is a won't fix but
Cesar may have some idea of doing something different.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-11-01 11:42
Message:
Confirmed here:
$ uname -a
MINGW32_NT-6.0 ... 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
$ mkdir --version
mkdir (GNU coreutils) 5.97
...
$ ls //domain/data/HoneywellManuals
...
ad20110.pdf ad21110.pdf ad40110.pdf ad41110.pdf
ad80110.pdf ad90110.pdf am03500.pdf am09501.pdf
...
works for me, but:
$ mkdir -p //domain/data/HoneywellManuals/foo/bar
fails silently, (with no evidence of directory creation anywhere, in my
case).
However:
$ mkdir //domain/data/HoneywellManuals/foo
$ mkdir //domain/data/HoneywellManuals/foo/bar
does work as expected, as does:
$ mkdir -p /w/HoneywellManuals/foo/bar
(W: is a mapped network drive, set up by my network/domain administrator,
to represent //domain/data).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
------------------------------
Message: 3
Date: Tue, 02 Nov 2010 17:01:30 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3101688 ] can't open files larger
than 4GB.
To: noreply@sourceforge.net
Message-ID: <E1PDKEk-0003Ae-GA@sfs-web-8.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3101688, was opened at 2010-11-02 13:01
Message generated for change (Tracker Item Submitted) made by shayap
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3101688&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shayap (shayap)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't open files larger than 4GB.
Initial Comment:
when I try to open files that are larger than 4GB.
this simple program
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE64_SOURCE 1
#define _LARGEFILE_SOURCE 1
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char *argv[])
{
FILE * filp;
int fd;
if ( (filp = fopen(argv[1], "r+")) == NULL) {
perror("fopen: failed to open");
}
if ( (fd = open(argv[1], O_RDWR)) == -1) {
perror("open: failed to open");
}
}
fails at both fopen and open when argv[1] is a file that is larger than 4GB. \
succeeds when the file is smaller than 4GB.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3101688&group_id=2435
------------------------------
Message: 4
Date: Tue, 02 Nov 2010 17:03:25 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3101688 ] can't open files larger
than 4GB.
To: noreply@sourceforge.net
Message-ID: <E1PDKGb-0008BT-Ef@sfs-web-4.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3101688, was opened at 2010-11-02 13:01
Message generated for change (Comment added) made by shayap
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3101688&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shayap (shayap)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't open files larger than 4GB.
Initial Comment:
when I try to open files that are larger than 4GB.
this simple program
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE64_SOURCE 1
#define _LARGEFILE_SOURCE 1
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char *argv[])
{
FILE * filp;
int fd;
if ( (filp = fopen(argv[1], "r+")) == NULL) {
perror("fopen: failed to open");
}
if ( (fd = open(argv[1], O_RDWR)) == -1) {
perror("open: failed to open");
}
}
fails at both fopen and open when argv[1] is a file that is larger than 4GB. \
succeeds when the file is smaller than 4GB.
----------------------------------------------------------------------
> Comment By: shayap (shayap)
Date: 2010-11-02 13:03
Message:
info, I forgot to include.
This is win7 - 64 bit
gcc version 4.5.1 (tdm-1)
ld version 2.20.51.20100613
uname -a (transcribed)
MINGW32_NT-6.1 TRILLIAN2 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3101688&group_id=2435
------------------------------
Message: 5
Date: Tue, 02 Nov 2010 19:00:12 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3101688 ] can't open files larger
than 4GB.
To: noreply@sourceforge.net
Message-ID: <E1PDM5c-0008IG-87@sfs-web-2.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3101688, was opened at 2010-11-02 13:01
Message generated for change (Comment added) made by shayap
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3101688&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shayap (shayap)
Assigned to: Nobody/Anonymous (nobody)
Summary: can't open files larger than 4GB.
Initial Comment:
when I try to open files that are larger than 4GB.
this simple program
#define _FILE_OFFSET_BITS 64
#define _LARGEFILE64_SOURCE 1
#define _LARGEFILE_SOURCE 1
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
int main(int argc, char *argv[])
{
FILE * filp;
int fd;
if ( (filp = fopen(argv[1], "r+")) == NULL) {
perror("fopen: failed to open");
}
if ( (fd = open(argv[1], O_RDWR)) == -1) {
perror("open: failed to open");
}
}
fails at both fopen and open when argv[1] is a file that is larger than 4GB. \
succeeds when the file is smaller than 4GB.
----------------------------------------------------------------------
> Comment By: shayap (shayap)
Date: 2010-11-02 15:00
Message:
so mingw obviously supports this as other libs I have (libdvdcss and
libcdio) work fine w/ the large file.
Hoewve,r I can't for the life of me figure out how to do it correctly in
my own program. It seems very non obvious.
----------------------------------------------------------------------
Comment By: shayap (shayap)
Date: 2010-11-02 13:03
Message:
info, I forgot to include.
This is win7 - 64 bit
gcc version 4.5.1 (tdm-1)
ld version 2.20.51.20100613
uname -a (transcribed)
MINGW32_NT-6.1 TRILLIAN2 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3101688&group_id=2435
------------------------------
Message: 6
Date: Wed, 03 Nov 2010 06:09:13 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation
To: noreply@sourceforge.net
Message-ID: <E1PDWX3-0006ln-Ss@sfs-web-9.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3091216, was opened at 2010-10-20 11:39
Message generated for change (Comment added) made by
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gwowen ()
Assigned to: Cesar Strauss (cstrauss)
Summary: mkdir -p fails with //server/dir/subdir notation
Initial Comment:
If you use UNC with forward slashes to designate network address, then mkdir -p won't \
create parents when necessary
$ ls //superserver/data/tmp/foo
ls: //superserver/data/tmp/foo: No such file or directory
$ mkdir //superserver/data/tmp/foo
$ ls //superserver/data/tmp/foo
The directory exists on the network resource, which is as expected...
However if I now do
$ mkdir -p //superserver/data/tmp/foo/bar/baz/shazam
I get no error message, but
$ ls //superserver/data/tmp/foo/bar/baz/shazam
ls: //superserver/data/tmp/foo/bar/baz/shazam: No such file or directory
In fact, the requested directory hierarchy gets made under the root directory, \
exactly as if I had a single leading slash, not a double leading slash...
This is MSYS-1.0.11, mkdir --version says: mkdir (GNU coreutils) 5.97
----------------------------------------------------------------------
Comment By: gwowen ()
Date: 2010-11-03 06:09
Message:
Thanks for looking at this: earnie, I can see your point, but whatever the
solution, I think the behaviour should be consistent: the parsing of
//foo/bar/baz should not depend on whether I pass the -p switch. At the
moment, it does.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2010-11-02 12:57
Message:
The // becomes / as a feature of MSYS to help with /C style switches in
Windows. To use //domain/some/dir you need to add another / so for MSYS
the proper notation for using domains is ///domain/some/dir since multiple
/ removes one / from the string. In my thinking this is a won't fix but
Cesar may have some idea of doing something different.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-11-01 15:42
Message:
Confirmed here:
$ uname -a
MINGW32_NT-6.0 ... 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
$ mkdir --version
mkdir (GNU coreutils) 5.97
...
$ ls //domain/data/HoneywellManuals
...
ad20110.pdf ad21110.pdf ad40110.pdf ad41110.pdf
ad80110.pdf ad90110.pdf am03500.pdf am09501.pdf
...
works for me, but:
$ mkdir -p //domain/data/HoneywellManuals/foo/bar
fails silently, (with no evidence of directory creation anywhere, in my
case).
However:
$ mkdir //domain/data/HoneywellManuals/foo
$ mkdir //domain/data/HoneywellManuals/foo/bar
does work as expected, as does:
$ mkdir -p /w/HoneywellManuals/foo/bar
(W: is a mapped network drive, set up by my network/domain administrator,
to represent //domain/data).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
------------------------------
Message: 7
Date: Fri, 05 Nov 2010 11:54:20 +0000
From: SF/projects/mingw notification list
<mingw-notify@lists.sourceforge.net>
Subject: [MinGW-notify] [ mingw-Bugs-3091216 ] mkdir -p fails with
//server/dir/subdir notation
To: noreply@sourceforge.net
Message-ID: <E1PEKs8-0007uj-SF@sfs-web-1.v29.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #3091216, was opened at 2010-10-20 07:39
Message generated for change (Comment added) made by earnie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gwowen ()
Assigned to: Cesar Strauss (cstrauss)
Summary: mkdir -p fails with //server/dir/subdir notation
Initial Comment:
If you use UNC with forward slashes to designate network address, then mkdir -p won't \
create parents when necessary
$ ls //superserver/data/tmp/foo
ls: //superserver/data/tmp/foo: No such file or directory
$ mkdir //superserver/data/tmp/foo
$ ls //superserver/data/tmp/foo
The directory exists on the network resource, which is as expected...
However if I now do
$ mkdir -p //superserver/data/tmp/foo/bar/baz/shazam
I get no error message, but
$ ls //superserver/data/tmp/foo/bar/baz/shazam
ls: //superserver/data/tmp/foo/bar/baz/shazam: No such file or directory
In fact, the requested directory hierarchy gets made under the root directory, \
exactly as if I had a single leading slash, not a double leading slash...
This is MSYS-1.0.11, mkdir --version says: mkdir (GNU coreutils) 5.97
----------------------------------------------------------------------
> Comment By: Earnie Boyd (earnie)
Date: 2010-11-05 07:54
Message:
The solution for passing switches in Microsoft style to "native" windows
programs was a feature to remove one / from multiple // so that the /
wouldn't be translated from POSIX to Windows paths. So one can easily do
``cmd //c dir'' from the MSYS shell. But this means that any // will
become / regardless of the purpose of //. To work around that issue you
simply add one more / to // so that it becomes /// and MSYS will remove one
and pass it on. The current correct method of specifying the
\\server\some\dir in MSYS is ///server/some/dir regardless of where on the
command line it is used.
I consider that the bug here is that //server/some/dir is working in some
of the cases instead of none of the cases since it really should be
///server/some/dir for any of the cases to work.
----------------------------------------------------------------------
Comment By: gwowen ()
Date: 2010-11-03 02:09
Message:
Thanks for looking at this: earnie, I can see your point, but whatever the
solution, I think the behaviour should be consistent: the parsing of
//foo/bar/baz should not depend on whether I pass the -p switch. At the
moment, it does.
----------------------------------------------------------------------
Comment By: Earnie Boyd (earnie)
Date: 2010-11-02 08:57
Message:
The // becomes / as a feature of MSYS to help with /C style switches in
Windows. To use //domain/some/dir you need to add another / so for MSYS
the proper notation for using domains is ///domain/some/dir since multiple
/ removes one / from the string. In my thinking this is a won't fix but
Cesar may have some idea of doing something different.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2010-11-01 11:42
Message:
Confirmed here:
$ uname -a
MINGW32_NT-6.0 ... 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msys
$ mkdir --version
mkdir (GNU coreutils) 5.97
...
$ ls //domain/data/HoneywellManuals
...
ad20110.pdf ad21110.pdf ad40110.pdf ad41110.pdf
ad80110.pdf ad90110.pdf am03500.pdf am09501.pdf
...
works for me, but:
$ mkdir -p //domain/data/HoneywellManuals/foo/bar
fails silently, (with no evidence of directory creation anywhere, in my
case).
However:
$ mkdir //domain/data/HoneywellManuals/foo
$ mkdir //domain/data/HoneywellManuals/foo/bar
does work as expected, as does:
$ mkdir -p /w/HoneywellManuals/foo/bar
(W: is a mapped network drive, set up by my network/domain administrator,
to represent //domain/data).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3091216&group_id=2435
------------------------------
------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a
Billion" shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
------------------------------
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest, Vol 54, Issue 2
*******************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic