g, so a quick help would be appreciated,
> > > > as I cannot figure this out after several hours of digging.
> > > >
> > > > Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value
> > > > must the CreationTime member of F
/usr/bin/stat returns "Birth: -" for some files. Which value
must the CreationTime member of FILE_BASIC_INFORMATION have to cause
/usr/bin/stat ti return "-"? 0, -1, or something else?
In a related matter:
The Win32 FILE_BASIC_INFORMATION structure defines four time va
On Apr 5 04:26, Martin Wege via Cygwin wrote:
> On Fri, Apr 5, 2024 at 2:05 AM Martin Wege wrote:
> >
> > Hello,
> >
> > I have problems with debugging, so a quick help would be appreciated,
> > as I cannot figure this out after several hours of digging.
>
.
Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value
must the CreationTime member of FILE_BASIC_INFORMATION have to cause
/usr/bin/stat ti return "-"? 0, -1, or something else?
https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/stat.c#n1618
=
On Fri, Apr 5, 2024 at 2:05 AM Martin Wege wrote:
>
> Hello,
>
> I have problems with debugging, so a quick help would be appreciated,
> as I cannot figure this out after several hours of digging.
>
> Cygwin /usr/bin/stat returns "Birth: -" for some files. Whic
On Fri, Apr 5, 2024 at 2:55 AM Brian Inglis via Cygwin
wrote:
>
> On 2024-04-04 18:05, Martin Wege via Cygwin wrote:
> > I have problems with debugging, so a quick help would be appreciated,
> > as I cannot figure this out after several hours of digging.
> >
> >
On 2024-04-04 18:05, Martin Wege via Cygwin wrote:
I have problems with debugging, so a quick help would be appreciated,
as I cannot figure this out after several hours of digging.
Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value
must the CreationT
Hello,
I have problems with debugging, so a quick help would be appreciated,
as I cannot figure this out after several hours of digging.
Cygwin /usr/bin/stat returns "Birth: -" for some files. Which value
must the CreationTime member of FILE_BASIC_INFORMATION have to cause
/usr/b
On Mar 9 15:29, Marcin Wisnicki via Cygwin wrote:
> I did more testing and found out that the problem does not happen in
> cygwin by default because cygwin mounts with acl which doesn't do
> header sniffing while msys uses noacl.
>
> Testing on an mp4 file in OneDrive, when I use noacl in cygwin
n wrote:
> >>> On 3/8/2024 7:52 AM, Thomas Wolff via Cygwin wrote:
> >>>> Am 08.03.2024 um 11:37 schrieb Corinna Vinschen via Cygwin:
> >>>>> FILE_OPEN_NO_RECALL (0x0040)
> >>>>> [...]
> >>>>> This sounds li
(0x0040)
[...]
This sounds like we could simply add this flag to all NtOpenFile
used for path conversion or stat-like calls, without having to care
for any file attributes specificially.
Does that make sense?
Sounds good, without even studying the other details...
I speculate some more handling would
ILE_OPEN_NO_RECALL (0x0040)
> > > > [...]
> > > > This sounds like we could simply add this flag to all NtOpenFile
> > > > used for path conversion or stat-like calls, without having to care
> > > > for any file attributes specificially.
> > > >
> > > >
e recall can take up to several minutes in a
> > > hierarchical storage management environment. The clients can
> > > specify
> > > this option to avoid such delays.
> > >
> > > This sounds like we could simply add this flag to all NtOpenFile
>
add this flag to all NtOpenFile
used for path conversion or stat-like calls, without having to care
for any file attributes specificially.
Does that make sense?
Sounds good, without even studying the other details...
I speculate some more handling would still be needed to avoid executable
dete
rom tertiary storage
such as tape. A file recall can take up to several minutes in a
hierarchical storage management environment. The clients can specify
this option to avoid such delays.
This sounds like we could simply add this flag to all NtOpenFile
used for path conversio
ed from tertiary storage
such as tape. A file recall can take up to several minutes in a
hierarchical storage management environment. The clients can specify
this option to avoid such delays.
This sounds like we could simply add this flag to all NtOpenFile
used for path conversio
Hi Jeffrey,
apart from the attribute stuff...
On Mar 6 13:55, Jeffrey Altman via Cygwin wrote:
> The default ProcessPlaceholderCompaibilityMode is PHCM_EXPOSE_PLACEHOLDERS
> which makes the FILE_ATTRIBUTE flags and reparse tags visible. Microsoft
> maintains a database of processes for which
Hi Jeffrey,
looks like writing our mails overlapped:
https://cygwin.com/pipermail/cygwin/2024-March/255622.html
On Mar 6 13:55, Jeffrey Altman via Cygwin wrote:
> On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote:
> > We can add an explicit call to
> >
> >
set, so they don't "represent
another named entity in the system". In other words, these reparse
points represent themselves rather than pointing to some other file, as
symlinks do.
Additionally the IO_REPARSE_TAG_CLOUD_* tags all have the directory bit
set so it seems they are used
On 3/6/2024 12:19 PM, Corinna Vinschen via Cygwin wrote:
We can add an explicit call to
RtlSetProcessPlaceholderCompatibilityMode (PHCM_EXPOSE_PLACEHOLDERS);
and we can recognize the IO_REPARSE_TAG_FILE_PLACEHOLDER and
IO_REPARSE_TAG_CLOUD_* tags during symlink evaluation, but even then
we
On Mar 6 06:54, Brian Inglis via Cygwin wrote:
> On 2024-03-06 06:28, Corinna Vinschen via Cygwin wrote:
> > On Mar 6 14:22, Corinna Vinschen via Cygwin wrote:
> > > Given these placeholder files are actually reparse points of type
> > > IO_REPARSE_TAG_FILE_PLACEHOLDER, we can handle them as
On 2024-03-06 06:28, Corinna Vinschen via Cygwin wrote:
On Mar 6 14:22, Corinna Vinschen via Cygwin wrote:
On Mar 5 19:54, Marcin Wisnicki via Cygwin wrote:
If I invoke ls or anything else that does stat inside OneDrive folder
it will trigger download of all files.
OneDrive uses placeholder
On Mar 6 14:22, Corinna Vinschen via Cygwin wrote:
> On Mar 5 19:54, Marcin Wisnicki via Cygwin wrote:
> > If I invoke ls or anything else that does stat inside OneDrive folder
> > it will trigger download of all files.
> >
> > OneDrive uses placeholder files[1
On Mar 5 19:54, Marcin Wisnicki via Cygwin wrote:
> If I invoke ls or anything else that does stat inside OneDrive folder
> it will trigger download of all files.
>
> OneDrive uses placeholder files[1] to represent remote files.
>
> I'm guessing reading file content in
If I invoke ls or anything else that does stat inside OneDrive folder
it will trigger download of all files.
OneDrive uses placeholder files[1] to represent remote files.
I'm guessing reading file content in stat is to support detection of
actually executable files as in here[2]?
I think
Don't leak a Windows file handle if stat() is called with a valid
filename, but invalid stat buffer pointer.
We do not destroy fh if an exception happens in the __try block, which
closes a Windows handle it has opened.
Fixes: 73151c54d581 ("syscalls.cc (stat_worker): Don't call build_
; > > }
> > > else if (!CTTY_IS_VALID (myself->ctty) && last_tty_dev
>
> That happens when CTTY is not assigned. In that case fhandler_nodevice
> is assigned at:
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/dtable.cc;h=18e0f3097823f00ff9651685be06583818eb2140;hb=e38f91d5a96c4554c69c833243e5afec8e3e90eb#l634
>
> Then fhandler_base::fstat() is called when stat() is called.
Oh, ok. Sorry, I was a bit puzzled by the missing else.
Please push.
Thanks,
Corinna
happens when CTTY is not assigned. In that case fhandler_nodevice
is assigned at:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/dtable.cc;h=18e0f3097823f00ff9651685be06583818eb2140;hb=e38f91d5a96c4554c69c833243e5afec8e3e90eb#l634
Then fhandler_base::fstat() is called when stat() is called.
--
Takashi Yano
Hi Takashi,
On Jul 7 12:34, Takashi Yano wrote:
> diff --git a/winsup/cygwin/dtable.cc b/winsup/cygwin/dtable.cc
> index 18e0f3097..2aae2fd65 100644
> --- a/winsup/cygwin/dtable.cc
> +++ b/winsup/cygwin/dtable.cc
> @@ -600,7 +600,13 @@ fh_alloc (path_conv& pc)
> case FH_TTY:
> if
As reported in
https://cygwin.com/pipermail/cygwin/2023-June/253888.html,
"Bad address" error occurs when stat() is called after the commit
3721a756b0d8 ("Cygwin: console: Make the console accessible from
other terminals.").
There are two problems in the current code. One
Takashi Yano (2):
Cygwin: stat(): Fix "Bad address" error on stat() for /dev/tty.
Cygwin: fstat(): Fix st_rdev returned by fstat() for /dev/tty.
winsup/cygwin/dtable.cc | 13 ++---
winsup/cygwin/fhandler/console.cc | 12 +++-
winsup/cygwi
Il 2023-04-19 03:10 L A Walsh ha scritto:
I'm a bit confused as to what char you are trying to access/use, as
U+F020 is in the Private Use area (PUA)
Since it's in the PUA, it seems its meaning could differ by
application/OS/User, no?
I.e. have no set definition
I mean you can use it in Cygwin
I'm a bit confused as to what char you are trying to access/use, as
U+F020 is in the Private Use area (PUA)
Since it's in the PUA, it seems its meaning could differ by
application/OS/User, no?
I.e. have no set definition
I mean you can use it in Cygwin to represent some character not usually
Il 2023-04-17 15:46 Gionatan Danti via Cygwin ha scritto:
First, I use the "dos" mount option to always trigger conversion of
space and dot at filename end into F+00xx chars. Now I am able to
create such strange-looking file (in Explorer) within cygwin itself.
For example, touch "zzs " now
Il 2023-04-17 11:05 Corinna Vinschen ha scritto:
It's actually not the "dos" mount option but specific filesystems
which trigger the conversion from U+0020 to U+F020.
OK.
However, the conversion back is handled in a piece of code which has
no information about the underlying filesystem, so
Greetings, Corinna Vinschen via Cygwin!
> On Apr 17 07:36, Gionatan Danti via Cygwin wrote:
>> Il 2023-04-14 23:01 Gionatan Danti via Cygwin ha scritto:
>> > Il 2023-04-14 22:25 Corinna Vinschen via Cygwin ha scritto:
>> > > We do that. You're just stumbling over tha fact that U+F020 is also
>>
On Apr 14 23:10, Brian Inglis via Cygwin wrote:
> On 2023-04-14 14:17, Gionatan Danti via Cygwin wrote:
> > Il 2023-04-14 21:00 Corinna Vinschen ha scritto:
> > > There's no (good) solution from inside Cygwin.
>
> > Yeah, I can only imagine how difficult is to be compatible with posix,
> > win32
On Apr 17 07:36, Gionatan Danti via Cygwin wrote:
> Il 2023-04-14 23:01 Gionatan Danti via Cygwin ha scritto:
> > Il 2023-04-14 22:25 Corinna Vinschen via Cygwin ha scritto:
> > > We do that. You're just stumbling over tha fact that U+F020 is also
> > > used as outlined in
> > >
Il 2023-04-14 23:01 Gionatan Danti via Cygwin ha scritto:
Il 2023-04-14 22:25 Corinna Vinschen via Cygwin ha scritto:
We do that. You're just stumbling over tha fact that U+F020 is also
used as outlined in
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
and
On 2023-04-14 14:17, Gionatan Danti via Cygwin wrote:
Il 2023-04-14 21:00 Corinna Vinschen ha scritto:
There's no (good) solution from inside Cygwin.
Yeah, I can only imagine how difficult is to be compatible with posix, win32 and
the likes.
Any chance you can just rename the files?
I
Il 2023-04-14 22:25 Corinna Vinschen via Cygwin ha scritto:
We do that. You're just stumbling over tha fact that U+F020 is also
used as outlined in
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars
and https://cygwin.com/pipermail/cygwin/2023-April/253478.html
Il 2023-04-14 22:40 Corinna Vinschen ha scritto:
This is really tricky. A new mount point flag could be used to
override
this behaviour on a per path basis. One problem is, the unicode ->
multibyte conversion when evaluating a symlink is done before it's
clear
where the symlink target is.
On Apr 14 22:17, Gionatan Danti via Cygwin wrote:
> Il 2023-04-14 21:00 Corinna Vinschen ha scritto:
> > There's no (good) solution from inside Cygwin.
> > [snip]
>
> Yeah, I can only imagine how difficult is to be compatible with posix, win32
> and the likes.
>
> > Any chance you can just
On Apr 14 22:21, Gionatan Danti via Cygwin wrote:
> Il 2023-04-14 21:54 Brian Inglis ha scritto:
> > UCSUR Under-ConScript Unicode Registry and its predecessor ConScript
> > Unicode Registry CSUR
> >
> > https://www.kreativekorp.com/ucsur/
> >
> > http://www.evertype.com/standards/csur/
Il 2023-04-14 21:54 Brian Inglis ha scritto:
UCSUR Under-ConScript Unicode Registry and its predecessor ConScript
Unicode Registry CSUR
https://www.kreativekorp.com/ucsur/
http://www.evertype.com/standards/csur/
unofficially register Unicode PUA glyphs for academic,
On Apr 14 13:54, Brian Inglis via Cygwin wrote:
> On 2023-04-14 13:00, Corinna Vinschen via Cygwin wrote:
> > On Apr 14 19:53, Gionatan Danti via Cygwin wrote:
> > > [1] https://sourceware.org/legacy-ml/cygwin/2009-11/msg00043.html
>
> > While this patch would have fixed your problem, a later
Il 2023-04-14 21:00 Corinna Vinschen ha scritto:
There's no (good) solution from inside Cygwin.
[snip]
Yeah, I can only imagine how difficult is to be compatible with posix,
win32 and the likes.
Any chance you can just rename the files?
I renamed the files, in fact.
However, it seems
On 2023-04-14 13:00, Corinna Vinschen via Cygwin wrote:
On Apr 14 19:53, Gionatan Danti via Cygwin wrote:
I have an issue with unreadable files with contain utf char U+F020 (which
appear as "middle dot with some space after") in their name.
stat on such a file results in &qu
On Apr 14 19:53, Gionatan Danti via Cygwin wrote:
> Dear list,
> I have an issue with unreadable files with contain utf char U+F020 (which
> appear as "middle dot with some space after") in their name.
>
> stat on such a file results in "no such file or director
Dear list,
I have an issue with unreadable files with contain utf char U+F020
(which appear as "middle dot with some space after") in their name.
stat on such a file results in "no such file or directory"
From here [1] it seems that a patch was contemplated many years ag
Corinna Vinschen via Cygwin writes:
> Achim, I still wonder if vmstat shouldn't also work on Linux if the
> kernel hasn't been built with CONFIG_SMP. Does the vmstat code fail
> to take that into account?
The only thing that seems affected is "core id" and that should actually
be initialitzed as
t; > > When executing vmstat it returns the following error:
> > >
> > > "Unable to create system stat structure”
> > > [...]
> While that's obviously wrong, it's not the problem. It turns out that
> vmstat from procps-ng 4.0.2 stumbles over the fact, t
On Jan 16 11:19, Corinna Vinschen via Cygwin wrote:
> On Jan 15 22:04, System Administrator via Cygwin wrote:
> > Hello,
> >
> > I am trying to migrate my framework to Windows 11 running Cygwin.
> > When executing vmstat it returns the following error:
> >
Corinna Vinschen via Cygwin writes:
> I ran vmstat from procps-ng-4.0.2-1 under GDB and found that this
> vmstat tries to dynamically load libnuma.so or libnuma.1.so, both
> of which are naturally not available on Cygwin. So I guess vmstat
> from procps-ng-4.x still needs another patch.
Oh,
On Jan 15 22:04, System Administrator via Cygwin wrote:
> Hello,
>
> I am trying to migrate my framework to Windows 11 running Cygwin.
> When executing vmstat it returns the following error:
>
> "Unable to create system stat structure”
>
> Using the very same packag
o migrate my framework to Windows 11 running Cygwin.
>>> When executing vmstat it returns the following error:
"Unable to create system stat structure”
Using the very same packages (install files) on Windows 10, produces the proper
vmstat results (i.e. no error).
I’ve tried W11
vmstat it returns the following error:
"Unable to create system stat structure”
Using the very same packages (install files) on Windows 10, produces the proper
vmstat results (i.e. no error).
I’ve tried W11 pro and Enterprise - same difference (none.) Windows 11 is
running in a VMware VM. W11 is t
wrote:
Hello,
I am trying to migrate my framework to Windows 11 running Cygwin.
When executing vmstat it returns the following error:
"Unable to create system stat structure”
Using the very same packages (install files) on Windows 10, produces the proper
vmstat results (i.e. no error).
On Sun, 15 Jan 2023 at 22:05, System Administrator via Cygwin wrote:
>
> Hello,
>
> I am trying to migrate my framework to Windows 11 running Cygwin.
> When executing vmstat it returns the following error:
>
> "Unable to create system stat structure”
>
> Using the v
Hello,
I am trying to migrate my framework to Windows 11 running Cygwin.
When executing vmstat it returns the following error:
"Unable to create system stat structure”
Using the very same packages (install files) on Windows 10, produces the proper
vmstat results (i.e. no error).
I’ve trie
To reproduce, do (probably a non-cygwin 7za may be needed)
7za x long-cyr.zip
ls -lR t
#(ZIP FILE attached with a 0-length file in a subdirectory t)
I get a message like
/usr/bin/ls: cannot access
riggers procps's "BSD personality",
> where processes without a controlling terminal are supposed to be
> excluded by default:
>
> $ procps f
> PID TTYSTAT STIME COMMAND
>1809 ? Ss19:49 /usr/bin/mintty -
>1810 pty0 Ss19:49 \_ -zsh
>
ontrolling terminal are supposed to be
excluded by default:
$ procps f
PID TTYSTAT STIME COMMAND
1809 ? Ss19:49 /usr/bin/mintty -
1810 pty0 Ss19:49 \_ -zsh
2075 pty0 R 21:14 \_ procps f
Similarly, this should list the processes without a terminal, bu
On Tue, May 10, 2022, 8:45 PM Brian Inglis
wrote:
> Noticed some issues with x86 32 bit procps and checked /proc/pid/stat which
> looked misaligned compared to x86_64 64 bit, due to int64_t format
> mismatches.
> There were also issues with the tty_nr encoding (uses ctty whi
On May 10 08:44, Brian Inglis wrote:
>
> fix tty_nr maj/min bits, vmmaxrss units, and x86 format mismatch:
> ctty maj is 31:16, min is 15:0; tty_nr s/b maj 15:8, min 31:20, 7:0;
> vmmaxrss s/b bytes not pages;
> times all 64 bit - change formats of first two instances from %lu to %U;
> realign
fix tty_nr maj/min bits, vmmaxrss units, and x86 format mismatch:
ctty maj is 31:16, min is 15:0; tty_nr s/b maj 15:8, min 31:20, 7:0;
vmmaxrss s/b bytes not pages;
times all 64 bit - change formats of first two instances from %lu to %U;
realign sprintf formats and variables/values in more
On Apr 29 18:29, dreverser--- via Cygwin wrote:
> hello, i have issue for using stat for virtual cloned disk on windows/vmware
> st_dev give me the the same serial number
> and diff util doest work, because thinking path the same and there are
> no files for diff
>
> iam prop
On 2021-04-29 09:29, dreverser--- via Cygwin wrote:
hello, i have issue for using stat for virtual cloned disk on windows/vmware
st_dev give me the the same serial number
and diff util doest work, because thinking path the same and there are
no files for diff
iam propose improve winsup\cygwin
hello, i have issue for using stat for virtual cloned disk on windows/vmware
st_dev give me the the same serial number
and diff util doest work, because thinking path the same and there are
no files for diff
iam propose improve winsup\cygwin\mount.c
by add disk letter to st_dev
at this line
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 t
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 Cygwin 3.1.7 have
non-overlapping definitions
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=f36262d56ac78f04de147746ce4a85c6155e4a23
commit f36262d56ac78f04de147746ce4a85c6155e4a23
Author: Corinna Vinschen
Date: Wed Jan 29 15:14:05 2020 +0100
Cygwin: stat: fix st_mode of fifos
Signed-off-by: Corinna Vinschen
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=8574f8a1e4b02a4b47e2434111c4e2c382a9f046
commit 8574f8a1e4b02a4b47e2434111c4e2c382a9f046
Author: Anton Lavrentiev via cygwin-patches
Date: Sat Nov 30 22:58:14 2019 -0500
Cygwin: /proc/[PID]/stat to pull process priority correctly
Fix to prior commit 5fa9a0e7 to address
https://cygwin.com/ml/cygwin/2019-08/msg00082.html
---
winsup/cygwin/fhandler_process.cc | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_process.cc
b/winsup/cygwin/fhandler_process.cc
index
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=111b34bb1b1718e815ea95d19630cea4cab1ddf5
commit 111b34bb1b1718e815ea95d19630cea4cab1ddf5
Author: Corinna Vinschen
Date: Wed Mar 13 11:26:58 2019 +0100
Cygwin: proc: add missing LF to /proc//stat output
Signed-off
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=57f1c81fb3e4a2581f5421350315755b07e509c8
commit 57f1c81fb3e4a2581f5421350315755b07e509c8
Author: Corinna Vinschen
Date: Tue Mar 12 11:34:50 2019 +0100
Cygwin: proc: let stat info always succeed
There's no good reason
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=4ce7e1bbaacf007197e348e4d11ec6258f508873
commit 4ce7e1bbaacf007197e348e4d11ec6258f508873
Author: Corinna Vinschen
Date: Tue Mar 12 11:20:42 2019 +0100
Cygwin: proc: don't request PROCESS_VM_READ perms for stat
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=7aca27b4fe553657d057dce90de13be97068fd4a
commit 7aca27b4fe553657d057dce90de13be97068fd4a
Author: Corinna Vinschen
Date: Sun Jan 6 20:18:14 2019 +0100
Cygwin: introduce fhandler_process_fd and add stat(2) handling
move
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=e113d126848f57fb5113cb76dfe9521e1521b79b
commit e113d126848f57fb5113cb76dfe9521e1521b79b
Author: Corinna Vinschen <cori...@vinschen.de>
Date: Mon Feb 12 22:10:08 2018 +0100
Cygwin: /proc//stat: Fix time handling
*
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=a10d96923188977446ebd84323b47f7085fb5cb4
commit a10d96923188977446ebd84323b47f7085fb5cb4
Author: Corinna Vinschen <cori...@vinschen.de>
Date: Mon Jan 11 12:35:41 2016 +0100
Return unique inode numbers when calling stat
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.
t;\320\260\320\261\320\262\320\260\320\261\320\262\320\260\320\261 [snipped]"
>> "abababababaababababa [snipped]"
>>
>> ... but passing these strings in turn to lstat() or stat() returns 0 as
>> expected for all except for the long Cyrillic filename.
> NAME
\320\262\320\260\320\261 [snipped]"
> "abababababaababababa [snipped]"
>
> ... but passing these strings in turn to lstat() or stat() returns 0 as
> expected for all except for the long Cyrillic filename.
NAME_MAX is 255. On Windows this is the number of UTF-16 chars
unfortun
obtain the corresponding
filename strings using readdir_r()...
"\320\260\320\261\320\262\320\260\320\261.txt"
"\320\260\320\261\320\262\320\260\320\261\320\262\320\260\320\261 [snipped]"
"abababababaababababa [snipped]"
... but passing these strings in turn to lstat() or st
On Aug 27 16:28, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
-v, please. What means obviously here? Did you ask Netapp?
No, I've tried all combinations of parameters to the open calls to
absolutely no avail. I then started to look at what the
Corinna Vinschen corinna-cygwin at cygwin.com writes:
[...]
The patch with the fallback to FileFsSizeInformation works as expected.
Btw., one other hare-brained idea would be if the Netapp FS has a
somewhat different idea of the size of FILE_FS_FULL_SIZE_INFORMATION,
maybe due to a
On Aug 28 14:58, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
[...]
The patch with the fallback to FileFsSizeInformation works as expected.
Btw., one other hare-brained idea would be if the Netapp FS has a
somewhat different idea of the size of
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I've just set up for a build and ran into this (with the snapshot sources
from 2014-08-19 since these were the ones I had at hand):
Sorted. I just did a native build from the 2014-08-25 snapshot (which is
also the installed version). Now
On Aug 27 09:23, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
I've just set up for a build and ran into this (with the snapshot sources
from 2014-08-19 since these were the ones I had at hand):
Sorted. I just did a native build from the 2014-08-25 snapshot
Corinna Vinschen corinna-cygwin at cygwin.com writes:
It's easier to do this from CVS. It also allows to create diffs
most easily. Did you build outside the source dir, as required?
No can do CVS here... I just did a ./configure make, which seemed to
work (it built into
Corinna Vinschen corinna-cygwin at cygwin.com writes:
The call to NtQueryVolumeInformationFile() in
fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
fails with STATUS_INVALID_PARAMETER. This is a NetApp bug, but we may
be able to workaround it.
The bug (if there is one)
On Aug 27 15:06, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
The call to NtQueryVolumeInformationFile() in
fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
fails with STATUS_INVALID_PARAMETER. This is a NetApp bug, but we may
be able to
On Aug 27 17:15, Corinna Vinschen wrote:
On Aug 27 15:06, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
The call to NtQueryVolumeInformationFile() in
fhandler_disk_file::fstatvfs() in fhandler_disk_file.cc (line 737ff),
fails with STATUS_INVALID_PARAMETER.
Corinna Vinschen corinna-cygwin at cygwin.com writes:
-v, please. What means obviously here? Did you ask Netapp?
No, I've tried all combinations of parameters to the open calls to
absolutely no avail. I then started to look at what the VolumeInformation
call is supposed to be doing and
On Aug 27 16:28, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
-v, please. What means obviously here? Did you ask Netapp?
No, I've tried all combinations of parameters to the open calls to
absolutely no avail. I then started to look at what the
On Aug 27 19:04, Corinna Vinschen wrote:
On Aug 27 16:28, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
-v, please. What means obviously here? Did you ask Netapp?
No, I've tried all combinations of parameters to the open calls to
absolutely no avail. I
Corinna Vinschen corinna-cygwin at cygwin.com writes:
That's the real output? No error message, just the names of the
mount points? Is that the 32 or 64 bit Cygwin?
Yes:
df /home/gratz
df: ‘/home/gratz’
Given the lack of access to netapp drives, if this is a bug in Cygwin
(which seems
On Aug 26 09:14, Achim Gratz wrote:
Corinna Vinschen corinna-cygwin at cygwin.com writes:
(which seems likely in this case) I would need your cooperation to run
debugging sessions to be able to come up with a fix. Is that ok?
Sorry, can't do that.
Then you have to build your own Cygwin
Corinna Vinschen corinna-cygwin at cygwin.com writes:
Then you have to build your own Cygwin DLL for testing.
I've just set up for a build and ran into this (with the snapshot sources
from 2014-08-19 since these were the ones I had at hand):
ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall
1 - 100 of 346 matches
Mail list logo
