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 Cyg
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 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() itsel
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 would
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 e
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 bas
Hi,
On 15 Jan 2013 23:33, Shaddy Baddah wrote:
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, perhaps
ca
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 everythi
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
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 the
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
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
> >
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 i
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 substituted
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,
" ma
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 a
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
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" -> "
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
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 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("~/..")'
>
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 "", line
Sjors Gielen, le Tue 24 Feb 2009 16:54:28 +0100, a écrit :
> Here's the test case and output:
>
> #include
> 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 -Wa
> 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
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 concessio
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
> perf
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
>>>
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 abov
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 out
> 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
> 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 C
[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
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
>>eve
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 post
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
[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 f
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
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 pre
> 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
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 th
> > 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
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
>
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
> -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,
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 b
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
> >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
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
> -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
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 cau
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 agains
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??
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
> >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.
I
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 th
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
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
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
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
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 w
ZXPLESPAC001, Ext a écrit:
Hi,
here is my question/problem (see the example program below):
-//
#include
#include
#include
#include
static int is_dir(char * dr)
{
struct stat st;
if(stat(dr, &st) == -1)
{
perror("stat");
return -
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 fie
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
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,
> 1045764
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 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 d
68 matches
Mail list logo
