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 CreationTime
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
Cygwin 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 soun
(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
00)
> > > > [...]
> > > > 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.
> > > >
> > > >
ecall 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 P
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
> >
> >RtlSetProcessPlaceholderComp
e bit 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
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 s
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 symb
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 conten
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
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 result
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 th
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 a
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
> > > https://cygwin.com
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 https
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 r
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
Ah,
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. O
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 rename
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, artificial,
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 foll
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 tha
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 "
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 directory&quo
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 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, great
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
tat 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
't/'$'\321\217\321\217\321\217\321\217\321\217\321\217\321\217\321\217\321\217
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 that
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
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.
uot;\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.
>
61\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
unf
can 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()
On Aug 28 14:58, Achim Gratz wrote:
> Corinna Vinschen 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_
Corinna Vinschen 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 misunder
On Aug 27 16:28, Achim Gratz wrote:
> Corinna Vinschen 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
> cal
On Aug 27 19:04, Corinna Vinschen wrote:
> On Aug 27 16:28, Achim Gratz wrote:
> > Corinna Vinschen 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 the
On Aug 27 16:28, Achim Gratz wrote:
> Corinna Vinschen 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
> cal
Corinna Vinschen 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 decided that this
On Aug 27 17:15, Corinna Vinschen wrote:
> On Aug 27 15:06, Achim Gratz wrote:
> > Corinna Vinschen 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 i
On Aug 27 15:06, Achim Gratz wrote:
> Corinna Vinschen 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 workaroun
Corinna Vinschen 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) is that the d
Corinna Vinschen 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 x86_64_unknown_cygwin).
> > Now
On Aug 27 09:23, Achim Gratz wrote:
> Corinna Vinschen 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
Corinna Vinschen 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 what, is it
Corinna Vinschen 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):
>>
>> ccwrap -g -O2 -O3 -mtune=core2 -march=core2 -Wall -Wstrict-aliasing
> ^^^
> Huh?
>
> Did you specify -O
On Aug 26 15:00, Achim Gratz wrote:
> Corinna Vinschen 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 -
Corinna Vinschen 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 -Wstrict-aliasing
-
On Aug 26 09:14, Achim Gratz wrote:
> Corinna Vinschen 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 DLL for tes
Corinna Vinschen 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 likely in this
On Thu, Jul 03, 2014 at 12:25:05PM +0200, Corinna Vinschen wrote:
> I don't see any other mail from you except this one...
Sixth try:
Yes, that's the output - with no other clues. Maybe I did something dumb by
mounting my CIFS home shares into /home and changing permissions so that I can
access b
On Thu, Jul 03, 2014 at 12:25:05PM +0200, Corinna Vinschen wrote:
> I don't see any other mail from you except this one...
I've now tried some variations of mails, but none of them is making it through
to the list... :( As soon as I attach strace output (inline or as attachment),
the mails are s
On Jul 3 12:11, Alexander Schwab wrote:
> > That's the real output? No error message, just the names of the
> > mount points? Is that the 32 or 64 bit Cygwin?
> >
> > Given the lack of access to netapp drives, if this is a bug in Cygwin
> > (which seems likely in this case) I would need your co
> That's the real output? No error message, just the names of the
> mount points? Is that the 32 or 64 bit Cygwin?
>
> Given the lack of access to netapp drives, if this is a bug in Cygwin
> (which seems likely in this case) I would need your cooperation to run
> debugging sessions to be able to
On Jun 27 16:36, Alexander Schwab wrote:
> Hi everyone,
>
> I have mounted some NetApp CIFS shares and I've now realized that df does
> not return filesystem statistics for these shares. It looks like I can't
> figure
> out why that is. Can anyone explain this behavior to me?
>
> I'm using cygw
Hi everyone,
I have mounted some NetApp CIFS shares and I've now realized that df does
not return filesystem statistics for these shares. It looks like I can't figure
out why that is. Can anyone explain this behavior to me?
I'm using cygwin 1.7.30(0.272/5/3).
$ df
df: `/home/admaschwab'
df: `/
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
#x27; && tilde_file_exists (text)) {
*r++ = '\\';
+ }
*r++ = *s;
}
*r = '\0';
diff --git a/general.c b/general.c
index fdadf1d..b279cbe 100644
--- a/general.c
+++ b/general.c
@@ -544,6 +544,28 @@ file_exists (fn)
}
int
+tilde_file_ex
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
without a good clue of
>> what you're doing.
>>
>>> in our script we used asterisk to copy the folder contents. but it is
>>> failing with the error.
>>
>> H:\>>cp -rf D:\ostore_7.4_int_bld\package\ostore\*
>>> \\rdlserv\cdimage\ObjectSto
o copy the folder contents. but it is
>> failing with the error.
>
> H:\>>cp -rf D:\ostore_7.4_int_bld\package\ostore\*
>> \\rdlserv\cdimage\ObjectStore\ostore\7.4.0\winnt_vc100\20121226\Win_32_VS_2010
>> cp: cannot stat `D:\\ostore_7.4_int_bld\\package\\ostore\\*':
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() che
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
1 - 100 of 298 matches
Mail list logo
