On Oct 19 02:06, Phil Budne wrote:
> While checking if an OSS project of mine (www.snobol4.org/csnobol4)
> compiled cleanly under Cygwin, I was happy to discover that struct
> stat contains file birth time as on various BSD based systems.
>
> BUT, I was unhappy to find out that MacOS 10.15 and
On 25/12/2015 01:04, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
>
>>> First, I have read the FAQ and this mailing archive :)
>>>
[..]
>
>> NAME_MAX is 255. On Windows this is the number of UTF-16 chars
>> unfortunately. On POSIX systems (as on Cygwin) this is the
>> number of bytes.
Greetings, Corinna Vinschen!
>> First, I have read the FAQ and this mailing archive :)
>>
>> Here is the problem I meet:
>>
>> In a directory are placed three files using windows 8's explorer:
>> - a short Cyrillic filename "абваб.txt"
>> - a long Cyrillic filename
>>
On Dec 23 20:44, Denis Corbin wrote:
> Hi,
>
> First, I have read the FAQ and this mailing archive :)
>
> Here is the problem I meet:
>
> In a directory are placed three files using windows 8's explorer:
> - a short Cyrillic filename "абваб.txt"
> - a long Cyrillic filename
>
On 02/07/2013 12:00 AM, Shaddy Baddah wrote:
Please find the patch discussed attached. It probably needs to be a bit
more generic, maybe with some precompiler directives to limit it to
cygwin? Although if it is just for cygwin, perhaps it can just go in the
cygports patch?
The build of bash
Am 07.02.2013 16:30, schrieb Eric Blake:
...
...
the fact that cygwin's handling of .. is not POSIX-compliant. I think a
better fix would be to change file_exists() itself instead of adding a
misnamed wrapper function; then bashline.c wouldn't even need patching.
The string 'tilde' need not
On Feb 7 17:10, Thomas Wolff wrote:
Am 07.02.2013 16:30, schrieb Eric Blake:
...
...
the fact that cygwin's handling of .. is not POSIX-compliant. I think a
better fix would be to change file_exists() itself instead of adding a
misnamed wrapper function; then bashline.c wouldn't even
On Thu, Feb 07, 2013 at 05:23:22PM +0100, Corinna Vinschen wrote:
On Feb 7 17:10, Thomas Wolff wrote:
Am 07.02.2013 16:30, schrieb Eric Blake:
...
...
the fact that cygwin's handling of .. is not POSIX-compliant. I think a
better fix would be to change file_exists() itself instead of
Hi,
On 15 Jan 2013 23:33, Shaddy Baddah wrote:
snip
From what I make of it, there needs to be a patch that, although can
work generically, adds checks only required for Cygwin. And therefore
is specific to the Cygwin package.
The check would be an extension of the file_exists() function,
On Jan 14 16:37, Ryan Johnson wrote:
On 14/01/2013 3:24 PM, Stephan Mueller wrote:
Perhaps (as you may well have already considered):
- replace the path prefix by the mount point first? (this may be naïve
on my part, but it's not clear to me that .. early in a path should be
able
On Jan 14 23:14, Thomas Wolff wrote:
Am 14.01.2013 11:00, schrieb Corinna Vinschen:
...
The first step of converting a POSIX path to a Windows path is to
normalize the path. . and .. components are simply dropped:
a/b/./c - a\b\c
a/b/../c - a\c
which isn't correct already (even
Hi,
On 15 Jan 2013 03:13, Corinna Vinschen wrote:
It seems to me then that a patch to bash may be in order? I can see how
the bash check is the right thing to do. It doesn't want the special
tilde expansion to mask and disallow referencing of real tilde prefixed
paths. So the stat() check is
Greetings, Thomas Wolff!
The first step of converting a POSIX path to a Windows path is to
normalize the path. . and .. components are simply dropped:
a/b/./c - a\b\c
a/b/../c - a\c
which isn't correct already (even if everything exists) because if b is
a symbolic link, b/.. is
On 1/15/2013 2:39 PM, Andrey Repin wrote:
Greetings, Thomas Wolff!
The first step of converting a POSIX path to a Windows path is to
normalize the path. . and .. components are simply dropped:
a/b/./c - a\b\c
a/b/../c - a\c
which isn't correct already (even if everything exists)
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python -c 'import os; print os.stat(~/..)'
Traceback
Hi,
On 14/01/13 21:00, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python
On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
On Jan 14 10:27, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
The first step of converting a POSIX path to a Windows path is to
normalize the path. . and .. components are simply dropped:
a/b/./c - a\b\c
a/b/../c - a\c
[...]
Also:
On Jan 15 01:36, Shaddy Baddah wrote:
Hi,
On 14/01/13 21:00, Corinna Vinschen wrote:
On Jan 14 01:17, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed
On Mon, Jan 14, 2013 at 05:04:17PM +0100, Corinna Vinschen wrote:
On Jan 14 10:27, Christopher Faylor wrote:
On Mon, Jan 14, 2013 at 11:00:02AM +0100, Corinna Vinschen wrote:
The first step of converting a POSIX path to a Windows path is to
normalize the path. . and .. components are simply
On Jan 14 01:17, Christopher Faylor wrote:
It is a bug. It's not just ~. Any nonexistent directory will
work, like foo/...
Corinna wrote:
And it's a bug which isn't easily fixed. Since about the dawn of time,
Cygwin's core path handling evaluates the path in a non-POSIX manner,
mainly for
On 14/01/2013 3:24 PM, Stephan Mueller wrote:
Perhaps (as you may well have already considered):
- replace the path prefix by the mount point first? (this may be naïve
on my part, but it's not clear to me that .. early in a path should be able
to influence which mount point is
Am 14.01.2013 11:00, schrieb Corinna Vinschen:
...
The first step of converting a POSIX path to a Windows path is to
normalize the path. . and .. components are simply dropped:
a/b/./c - a\b\c
a/b/../c - a\c
which isn't correct already (even if everything exists) because if b is
a
On Mon, Jan 14, 2013 at 04:21:25PM +1100, Shaddy Baddah wrote:
In investigating this, I believe the issue I am having is due to how
stat() handles tilde prefixed paths. On linux we see:
linux$ $ python -c 'import os; print os.stat(~/..)'
Traceback (most recent call last):
File string, line 1,
Sjors Gielen, le Tue 24 Feb 2009 16:54:28 +0100, a écrit :
Here's the test case and output:
#include errno.h
int main() {
if(stat(test) != 0) perror(Calling stat() on test);
if(stat(test.exe) != 0) perror(Calling stat() on test.exe);
return 0;
}
Compile with -Wall,
Under *nix, I can use stat(2) of a directory to know when its
contents have changed (file added or deleted from it).
Under cygwin, this doesn't work because a directory's
modification time doesn't change when its contents change.
Any recommendations as to how
On 1/15/06, Christopher Faylor [EMAIL PROTECTED] wrote:
On Sat, Jan 14, 2006 at 11:37:33PM -0600, Gary R. Van Sickle wrote:
[snip]
I just wanted to make it clear that we aren't going to be
making any
special concessions to a product like a virus scanner which cause
perfectly acceptable code
On Mon, Jan 16, 2006 at 10:42:10PM -0600, * * wrote:
On 1/15/06, Christopher Faylor [EMAIL PROTECTED] wrote:
On Sat, Jan 14, 2006 at 11:37:33PM -0600, Gary R. Van Sickle wrote:
[snip]
I just wanted to make it clear that we aren't going to be
making any
special concessions to a product like a
Gary R. Van Sickle wrote:
[snip]
I just wanted to make it clear that we aren't going to be
making any
special concessions to a product like a virus scanner which cause
perfectly acceptable code to misbehave. If that is the
case then it
is a situation for the virus scanner to work
pmcferrin wrote:
Here is something a little OT
When making comparisons between multiple runs to run timing tests
before and after a change, it there a way I can guarantee more
consistent results? e.g. Condider the following:
time find . -print | wc -l
I can run the above
On Sat, Jan 14, 2006 at 11:37:33PM -0600, Gary R. Van Sickle wrote:
[snip]
I just wanted to make it clear that we aren't going to be
making any
special concessions to a product like a virus scanner which cause
perfectly acceptable code to misbehave. If that is the
case then it
is a situation for
pmcferrin wrote:
The stat(2) system call runs very slowly because it is constantlt
triggering the McAfee on-demand virus scanner to scan the file that
is being stat'ed. This may not seem like a big thing but I frequently
stat thousands of files at a batch. I find that the stat runs much
The stat(2) system call runs very slowly because it is constantlt
triggering the McAfee on-demand virus scanner to scan the file that
is being stat'ed. This may not seem like a big thing but I
frequently stat thousands of files at a batch. I find that the stat
runs much faster when I
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
I'm still researching, I was going to respond this is posting at a
later time with more insight, but before things get out-of-hand, I
wanted to jump in. I suppose I'm still hopeful that we can zero in
on what precisely is causing the
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
I'm still researching, I was going to respond this is posting at a
later time with more insight, but before things get out-of-hand, I
wanted to jump in. I suppose I'm still hopeful that we can zero in
on what precisely is causing
Brett Serkez wrote:
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
I'm still researching, I was going to respond this is posting at a
later time with more insight, but before things get out-of-hand, I
wanted to jump in. I suppose I'm still hopeful that we can zero in
on what
On Sat, Jan 14, 2006 at 04:18:43PM -0500, Brett Serkez wrote:
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
I'm still researching, I was going to respond this is posting at a
later time with more insight, but before things get out-of-hand, I
wanted to jump in. I suppose I'm still
[snip]
We are not going to visit the slippery slope of adding code to Cygwin
to work around other third party software.
I'm hoping and assuming it is going to be more a matter of making minor
changes, if it requires a major change, then it is more likely Microsoft
or some other vendor is at
Boy did I open a can of worms!
When I looked at the source of Cygwin1.dll a few years ago at the time, the stat(2)
basically called a MS API function to retreive the information and then did a simpe return.
I think it the faulty design of MS not to privide a function to get status information
Brett Serkez wrote:
[snip]
From what I've been seeing, I'm starting to suspect that the problem(s)
is
there in both cases, the scanner simply makes it much more noticable. I
do see more CPU consumption that I woud have expected even without the
virus scanner and the original poster's
On Sat, Jan 14, 2006 at 09:12:11PM -0500, Paul McFerrin wrote:
Brett Serkez wrote:
From what I've been seeing, I'm starting to suspect that the problem(s)
is there in both cases, the scanner simply makes it much more
noticable. I do see more CPU consumption that I woud have expected
even without
[snip]
I just wanted to make it clear that we aren't going to be
making any
special concessions to a product like a virus scanner which cause
perfectly acceptable code to misbehave. If that is the
case then it
is a situation for the virus scanner to work out. It's not a
requirement
From: Paul McFerrin
Sent: Saturday, January 14, 2006 5:19 PM
To: Cygwin@Cygwin.com
Subject: Re: stat(2) triggers on-demand virus scan
Boy did I open a can of worms!
No, it's like this on a regular, periodic basis.
When I looked at the source of Cygwin1.dll a few years ago at
the time
From: Brett Serkez
Sent: Saturday, January 14, 2006 3:19 PM
To: cygwin@cygwin.com; cygwin@cygwin.com
Subject: Re: stat(2) triggers on-demand virus scan
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
I'm still researching, I was going to respond this is posting
On Sat, Jan 14, 2006 at 12:56:11AM -0500, Paul McFerrin wrote:
I have an antique question.
I'm currently running cygwin.dll version: 1.3.6 ! (don't laugh). I use
cygwin daily in my work and I'm happy not to disturb things that are not
broken.
The stat(2) system call runs very slowly because
At 01:06 PM 6/24/2005, you wrote:
This buffer is being built for SpamAssassin which later
gives an error saying (to the effect)
Content-Length mismatch: Expected 818 bytes, got 798 bytes
My suspicion is that stat is counting cr-lf as two characters
but the input routines are treating these as
My suspicion is that stat is counting cr-lf as two
characters but the
input routines are treating these as one.
If the file has about 20 lines, then that's 20 missing characters???
Yes, this is right. And yes, this could be the cause of the
situation you're noticing.
Is there a
On Fri, 24 Jun 2005, Herb Martin wrote:
My suspicion is that stat is counting cr-lf as two characters but the
input routines are treating these as one.
If the file has about 20 lines, then that's 20 missing characters???
Yes, this is right. And yes, this could be the cause of the
On Fri, 24 Jun 2005, Igor Pechtchanski wrote:
On Fri, 24 Jun 2005, Herb Martin wrote:
My suspicion is that stat is counting cr-lf as two characters but the
input routines are treating these as one.
If the file has about 20 lines, then that's 20 missing characters???
Yes, this
Herb Martin wrote:
Is there a standard Cygwin 'idiom' or function for
dealing with this mismatch, or should I just re-invent
the wheel.
Sure. Don't use text mode. Open the file in binary mode (O_BINARY with
open(), b with fopen()), or call setmode(fd, O_BINARY) once open, or
link against
At 02:08 PM 6/24/2005, you wrote:
My suspicion is that stat is counting cr-lf as two
characters but the
input routines are treating these as one.
If the file has about 20 lines, then that's 20 missing characters???
Yes, this is right. And yes, this could be the cause of the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Herb Martin
Sent: Friday, June 24, 2005 1:08 PM
To: 'Cygwin List'
Subject: RE: stat file -- cygwin vs. Windows size?
My suspicion is that stat is counting cr-lf as two
characters but the
input
At 02:46 PM 6/24/2005, Gary R. Van Sickle wrote:
But hey, it's only the
first few years of the 21st century, maybe by the 22nd we'll have this whole
CRLF/LF/CR/LFCR thing sorted out.
Yeah, I'm guessing this will be solved just after the advent of practical
fusion reactors and the development of
Is there a standard Cygwin 'idiom' or function for dealing with this
mismatch, or should I just re-invent the wheel.
If you actually believe that you want the file without cr/nl
conversion during a read, then you want to open it in binary
mode (fopen() with rb
instead of r or open()
The binary size is accurate, text, by its nature may never be correct on
any operating system, since it is buffered, parsed, etc by the OS in an OS
dependent way.
If you use a binary mode then you will be fine.
On Fri, 24 Jun 2005, Herb Martin wrote:
Is there a standard Cygwin 'idiom' or
Thanks folks -- the confirmation that I was on the right
path was a big help.
The suggestions to do it right were well intentioned
but impractical since I didn't want to take over support
for TWO major software packages (or either one for that
matter.)
A small patch seems to work. (Keep the
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason Pyeron
Sent: Friday, June 24, 2005 2:40 PM
To: cygwin@cygwin.com
Subject: RE: stat file -- cygwin vs. Windows size?
The binary size is accurate, text, by its nature may never be
correct
Reid Thompson wrote:
download coreutils from the gnu ftp site
./configure -- at first glance appears to configure with no errors
make -- at first glance appears to build with no errors
cp stat.exe to /bin
or
make install ( will attempt to install the just built versions of all
coreutils
On Jul 20 22:06, George wrote:
The 'stat' utility doesn't seem to be part of my Cygwin distribution.
Is this an error I've made during the installation or is it simply not
included?
It's not included since nobody volunteered to maintain coreutils so far.
Corinna
--
Corinna Vinschen
Corinna Vinschen wrote:
On Jul 20 22:06, George wrote:
The 'stat' utility doesn't seem to be part of my Cygwin distribution.
Is this an error I've made during the installation or is it simply not
included?
It's not included since nobody volunteered to maintain coreutils so far.
Corinna
download coreutils from the gnu ftp site
./configure -- at first glance appears to configure with no errors
make -- at first glance appears to build with no errors
cp stat.exe to /bin
or
make install ( will attempt to install the just built versions of all
coreutils executables -- this
On Apr 28 11:27, bertrand marquis wrote:
ZXPLESPAC001, Ext a ?crit:
The question is:
- is the behavior on Linux/Solaris normal ? I fact there ain't a '//bin'
only a '/bin',
but even all the shells treat them as representing the same path (BTW 'cd
//bin' on
cygwin/bash doesn't work ...)
ZXPLESPAC001, Ext a écrit:
Hi,
here is my question/problem (see the example program below):
-//
#include stdio.h
#include sys/types.h
#include sys/stat.h
#include errno.h
static int is_dir(char * dr)
{
struct stat st;
if(stat(dr, st) == -1)
{
On Thu, May 29, 2003 at 10:32:39PM -0400, Pierre A. Humblet wrote:
At 11:33 PM 5/28/2003 -0400, Christopher Faylor wrote:
On Tue, May 27, 2003 at 07:48:43PM -0400, Pierre A. Humblet wrote:
So I suggest a more radical approach: do not check for root dir at all
but
whenever FindFirstFile
At 11:33 PM 5/28/2003 -0400, Christopher Faylor wrote:
On Tue, May 27, 2003 at 07:48:43PM -0400, Pierre A. Humblet wrote:
So I suggest a more radical approach: do not check for root dir at all
but
whenever FindFirstFile fails with winerror 2 (although we know the
file did exist a few ms
On Thu, Feb 20, 2003 at 06:47:39PM -0500, Paul Swartz wrote:
On 20 Feb 2003 at 22:40, Corinna Vinschen wrote:
As you can see, there's also nothing which would help you in using the
result to identify the sockets as being the same. Even the timestamps
aren't identical.
No one field can
On Thu, Feb 20, 2003 at 02:02:40AM -0500, Paul Swartz wrote:
Content-Description: Mail message body
The man page for stat/fstat says that the results
returned should be the same. However, when asking
for the fstat on a unix socket, the result is not
the same. The attached python code
OK, here's what the script looks like on Cygwin:
-
stat from filename (49536, 1374655, 27579L, 1, 1005, 513, 51,
1045764368, 1045764368, 1045764368)
stat from fileno (49590, 1672, 2816L, 1, 0, 0, 0, 1045764368,
1045764368, 1045764368)
-
The lists correspond to (st_mode, st_ino, st_dev,
On Thu, Feb 20, 2003 at 01:23:43PM -0500, Paul Swartz wrote:
OK, here's what the script looks like on Cygwin:
-
stat from filename (49536, 1374655, 27579L, 1, 1005, 513, 51,
1045764368, 1045764368, 1045764368)
stat from fileno (49590, 1672, 2816L, 1, 0, 0, 0, 1045764368,
1045764368,
On 20 Feb 2003 at 22:40, Corinna Vinschen wrote:
I created a testcase which allows me to reproduce your observation.
First of all let me say that thanks to your report I could find the
problem in Cygwin which explains the differences between stat() and
fstat(). However, I'm not quite sure if
70 matches
Mail list logo
