Hi. I want to speed-up access to Google Drive from Cygwin and I want to disable
ReadFile when files are statted.
I did the following:
mkdir /cygnotexec
mount -obind,notexec "/cygdrive/c/ClusterStorage/gdrive/blahb...@gmail.com"
"/cygnotexec/basini...@gmail.com"
mount -obin
Greetings, ilya Basin!
> For several years I had this in my /etc/fstab.d/$USER
> C: /cygdrive/c none binary,noacl,posix=0,user 0 0
Unless you have a global /cygdrive override set to noacl as well, I have my
reservation about configuration.
> I switched from Cygwin x86 to x64 recen
Hi.
For several years I had this in my /etc/fstab.d/$USER
C: /cygdrive/c none binary,noacl,posix=0,user 0 0
I switched from Cygwin x86 to x64 recently and I noticed that even if `mount`
prints this:
$ mount | grep C:
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C
Hi!
-
AFAIK we found a resource or Win32 object refcount leak:
If I do a $ mount nfsdir_as_Y ; cd /cygdrive/y ; ls -l ; cd / ; umount
Y: #, the the VNetRoot used by the filesystem's kernel module is not
finalised (e.g. |MRxFinalizeVNetRoot()| is not being called).
If I do the same with
Greetings, Christopher Layne!
> I noticed recently while attempting to rsync directories from one drive to
> another that I was getting the familiar "NULL SID", "incorrectly ordered",
> etc. type ownership issues on the destination even though I use noacl for
> c
I noticed recently while attempting to rsync directories from one drive to
another that I was getting the familiar "NULL SID", "incorrectly ordered", etc.
type ownership issues on the destination even though I use noacl for cygdrive
mounts (I'm aware of the POSIX v
:
> >>> I've run into a problem with clang on Cygwin 3.5.1 and 3.6. My machine
> >>> does not have much disk space left, so I switched TMPDIR to the
> >>> network drive. But clang then failed, like this:
> >>>
> >>> $ cat x.c
> >
so I switched TMPDIR to the
network drive. But clang then failed, like this:
$ cat x.c
#include
int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
$ mkdir /cygdrive/t/tmpdir
$ TMPDIR=/cygdrive/t/tmpdir clang x.c
error: unable to open output file '/cygdrive
t; > network drive. But clang then failed, like this:
> >
> > $ cat x.c
> > #include
> > int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
> > $ mkdir /cygdrive/t/tmpdir
> > $ TMPDIR=/cygdrive/t/tmpdir clang x.c
> > error: unable
; $ cat x.c
> #include
> int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
> $ mkdir /cygdrive/t/tmpdir
> $ TMPDIR=/cygdrive/t/tmpdir clang x.c
> error: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o':
> 'Operation not permit
k space left, so I switched TMPDIR to the
> > network drive. But clang then failed, like this:
> >
> > $ cat x.c
> > #include
> > int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
> > $ mkdir /cygdrive/t/tmpdir
> > $ TMPDIR=/cyg
; $ cat x.c
> #include
> int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
> $ mkdir /cygdrive/t/tmpdir
> $ TMPDIR=/cygdrive/t/tmpdir clang x.c
> error: unable to open output file '/cygdrive/t/tmpdir/x-01564d.o':
> 'Operation not permit
Hello!
I've run into a problem with clang on Cygwin 3.5.1 and 3.6. My machine
does not have much disk space left, so I switched TMPDIR to the
network drive. But clang then failed, like this:
$ cat x.c
#include
int main(int ac, char *av[]) { puts("hello world"); return 0 ; }
$ mk
On 07.02.2024 20:27, Corinna Vinschen via Cygwin wrote:
On Feb 7 20:23, ASSI via Cygwin wrote:
Frank-Ulrich Sommer via Cygwin writes:
I'm trying to run cygsshd on my PC with Windows 11 and connect from a
linux machine. I have added the public key to
/cygdrive/c/Users/xxx
On Feb 7 20:27, Corinna Vinschen via Cygwin wrote:
> On Feb 7 20:23, ASSI via Cygwin wrote:
> > Frank-Ulrich Sommer via Cygwin writes:
> > > I'm trying to run cygsshd on my PC with Windows 11 and connect from a
> > > linux machine. I have added the public key to
On Feb 7 20:23, ASSI via Cygwin wrote:
> Frank-Ulrich Sommer via Cygwin writes:
> > I'm trying to run cygsshd on my PC with Windows 11 and connect from a
> > linux machine. I have added the public key to
> > /cygdrive/c/Users/xxx/.ssh/authorized_keys and create
On Feb 7 19:01, matthew patton via Cygwin wrote:
> > The problem seems to be that OpenSSH does not even arrive at checking the
> >home diretory> or the .ssh directory. It starts checking every directory in
> >the path and fails already at "/cygdrive/c/Users"
Frank-Ulrich Sommer via Cygwin writes:
> I'm trying to run cygsshd on my PC with Windows 11 and connect from a
> linux machine. I have added the public key to
> /cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link
> from /cygdrive/c/Users/xxx/.ssh to /home/xxx
> The problem seems to be that OpenSSH does not even arrive at checking the
>home diretory> or the .ssh directory. It starts checking every directory in
>the path and fails already at "/cygdrive/c/Users"
I don't think we can win an argument with Theo over how misguide
00:53, Frank-Ulrich Sommer via Cygwin wrote:
> >>>> I'm trying to run cygsshd on my PC with Windows 11 and connect from a
> >>>> linux machine. I have added the public key to
> >>>> /cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic lin
rom a linux
machine. I have added the public key to
/cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link from
/cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked the access
rights and mode of the .ssh directory (700 and belongs to user xxx) and the
authorized_keys
On 2024-02-05 18:36, Eliot Moss via Cygwin wrote:
On 2/5/2024 8:28 PM, Frank-Ulrich Sommer via Cygwin wrote:
On 05.02.2024 00:53, Frank-Ulrich Sommer via Cygwin wrote:
I'm trying to run cygsshd on my PC with Windows 11 and connect from a linux
machine. I have added the public key to
/cyg
s owned by "SYSTEM" (numeric: 18 according to stat) and only writable by Administrators and
SYSTEM. The mode cygwin shows for /cygdrive/c/Users is 0750 which should be OK.
So my question is: are "Administrators" and "SYSTEM" different users and does cygsshd accept SYS
t) and
only writable by Administrators and SYSTEM. The mode cygwin shows for /cygdrive/c/Users is 0750
which should be OK.
So my question is: are "Administrators" and "SYSTEM" different users and does
cygsshd accept SYSTEM (numeric 18) as a valid user who may own system directo
Hi,
I'm trying to run cygsshd on my PC with Windows 11 and connect from a linux
machine. I have added the public key to
/cygdrive/c/Users/xxx/.ssh/authorized_keys and created a symbolic link from
/cygdrive/c/Users/xxx/.ssh to /home/xxx/.ssh. As usual I checked the access
rights and mo
en attempting to reference a network drive. There have been a couple of
> >> other
> >> threads reporting this and talk about patches. Is there a fix coming for
> >> this
> >> in the production version of cygwin?
> >>
> >> $ cd /cygdrive/w
&g
patches. Is there a fix coming for this
in the production version of cygwin?
$ cd /cygdrive/w
bash: cd: /cygdrive/w: Too many levels of symbolic links
$ mount
C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin64 on / type ntfs (binary
re a fix coming for
> this
> in the production version of cygwin?
>
> $ cd /cygdrive/w
> bash: cd: /cygdrive/w: Too many levels of symbolic links
> $ mount
> C:/cygwin64/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin64/lib on /usr/lib type ntfs (binary,auto)
> C:/cyg
For the past couple of months the latest versions of cygwin produce this error
when attempting to reference a network drive. There have been a couple of other
threads reporting this and talk about patches. Is there a fix coming for this
in the production version of cygwin?
$ cd /cygdrive/w
etc/profile please also add /cygdrive/c/Windows/Sysnative to the end
of the PATH?
>
It doesn't add any other Windows folders so why this one.
### Summary
Why should Cygwin add Sysnative to $PATH? As a workaround for Microsoft's
failure to add Sysnative to %PATH%.
You have the
On 24/11/2020 14:52, Bill Stewart wrote:
> On Tue, Nov 24, 2020 at 12:25 AM Thomas Wolff wrote:
>
>>> and please note that SysNative appears nowhere!
>> That's because Sysnative is not a known folder. It is rather unknown
>> just because it is virtual :)
>> And that is the problem I tried to addres
On Tue, Nov 24, 2020 at 12:25 AM Thomas Wolff wrote:
> > and please note that SysNative appears nowhere!
>
> That's because Sysnative is not a known folder. It is rather unknown
> just because it is virtual :)
> And that is the problem I tried to address. In cygwin32, you can `cd
> $WINDIR/Sysnati
Am 19.11.2020 um 16:57 schrieb Brian Inglis:
On 2020-11-17 16:41, tealhill via Cygwin wrote:
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile please also add /cygdriv
On 2020/11/17 15:41, tealhill via Cygwin wrote:
### Summary
Why should Cygwin add Sysnative to $PATH? As a workaround for
Microsoft's failure to add Sysnative to %PATH%.
### Full explanation
Cygwin imports the Windows %PATH% variable at startup.
It would be ideal if Microsoft would add Sysn
On 2020-11-17 16:41, tealhill via Cygwin wrote:
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to the end
of the PATH?
&g
Greetings, tealhill!
> On 2020-11-17 4:23 PM, Thomas Wolff wrote:
>> Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>>
>>> Cygwin's /etc/profile sets the PATH.
>>>
>>> Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to
tealhill via Cygwin writes:
> ### Summary
>
> Why should Cygwin add Sysnative to $PATH? As a workaround for
> Microsoft's failure to add Sysnative to %PATH%.
With my maintainer hat for base-files on, I reject this proposal.
As already noted, there is no precedent for Cygwin doing things like
tha
On Tue, Nov 17, 2020 at 4:42 PM tealhill via Cygwin wrote:
> Therefore, I am suggesting that Cygwin work around Microsoft's omission.
> My suggested workaround is for Cygwin to add Sysnative to its own
> $PATH, automatically.
I don't think that should be a default behavior in cygwin and is
likely
On 2020-11-17 4:23 PM, Thomas Wolff wrote:
Am 17.11.2020 um 20:54 schrieb tealhill via Cygwin:
>>
Cygwin's /etc/profile sets the PATH.
Could /etc/profile please also add /cygdrive/c/Windows/Sysnative to
the end of the PATH?
>
It doesn't add any other Windows fold
ative. In this virtual folder, 32-bit Cygwin can see
all the 64-bit System32 tools.
If you try to run pluck.exe without specifying that it's in
/cygdrive/c/Windows/Sysnative, you'll get the output:
[user@host ~]$ pluck
-bash: pluck: command not found
This 'virtual folder'
rectory instead. It must look in
C:\Windows\Sysnative. In this virtual folder, 32-bit Cygwin can see all
the 64-bit System32 tools.
If you try to run pluck.exe without specifying that it's in
/cygdrive/c/Windows/Sysnative, you'll get the output:
[user@host ~]$ pluck
-bash: pluck
behaviour that confuses me regarding the
> case of a disk name:
>
> > ln -s "/cygdrive/c/Program Files" pf1
> > ln -s "/cygdrive/C/Program Files" pf2
> > ls -l pf*
> lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files
>
On Sat, Jun 13, 2020 at 1:50 PM Andrey Repin wrote:
> The cygdrive prefix is resolved, if no other mount points match.
> Since you have /mnt/C mount point, it is resolved first.
I wish it would have resolved it to the cygdrive prefix, because then
it would have worked (and would hav
Greetings, Wayne Davison!
> On Fri, Jun 12, 2020 at 4:05 AM Andrey Repin wrote:
>> And you've got exactly what you asked for.
> I think you missed the important part of the email. Distilled down,
> this is wrong:
> $ ln -s /cygdrive/C/Windows foo
> $ readlink foo
>
On Fri, Jun 12, 2020 at 4:05 AM Andrey Repin wrote:
> And you've got exactly what you asked for.
I think you missed the important part of the email. Distilled down,
this is wrong:
$ ln -s /cygdrive/C/Windows foo
$ readlink foo
/mnt/C/Windows
The symlink's value changed to a path
me regarding the
> case of a disk name:
>> ln -s "/cygdrive/c/Program Files" pf1
>> ln -s "/cygdrive/C/Program Files" pf2
>> ls -l pf*
> lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files
> lrwxrwxrwx 1 acn1 None 20 Jun 12 07:37
"/cygdrive/c/Program Files" pf1
ln -s "/cygdrive/C/Program Files" pf2
ls -l pf*
lrwxrwxrwx 1 acn1 None 25 Jun 12 07:37 pf1 -> /cygdrive/c/Program Files
lrwxrwxrwx 1 acn1 None 20 Jun 12 07:37 pf2 -> /mnt/C/Program Files
cygpath -ma ./pf1
C:/cygwin64/home/acn1/pf1
You see
On 3/2/20 3:53 PM, Marco Atzeri wrote:
Am 02.03.2020 um 21:17 schrieb Robert McBroom via cygwin:
Details in attached file
better in line next time.
Are you sure that the disk J is mounted in a Administrator account ?
Regards
Marco
USB drive Windows mounted on login. emacs shows the owner as
On Mon, Mar 2, 2020 at 11:08 PM Robert McBroom wrote:
Details in attached file
Hint: When asking for help in a mailing list, the less effort respondents
have to go through, the better.
It is better to put your information directly in the message rather than
attaching a file.
(Why attach a file
On 2020-03-02 23:08, Robert McBroom via cygwin wrote:
> Details in attached file
You most likely have Windows permissions problems, if all your tools are Cygwin.
Run which on each tool to see what you are actually running, and run cygcheck to
ensure they use cygwin1.dll.
You need to run against
Details in attached file
Strange problem cropping up. I chain scripts with command sequences for long
running numerical calculations executed from the initial mintty terminal.
Running from a non administrative session. The form is
---
#!/bin/bash
cd /cygdrive/j/tri60/221-1344c_1.933
mcnp62
On 2020-03-02 13:17, Robert McBroom via cygwin wrote:
> #!/bin/bash
> cd /cygdrive/j/tri60/221-1344c_1.642
>/home/xxx/grd.sh: line 2: cd:
> /cygdrive/j/tri60/221-
> 1344c_1.642: No such fi
Am 02.03.2020 um 21:17 schrieb Robert McBroom via cygwin:
Details in attached file
better in line next time.
Are you sure that the disk J is mounted in a Administrator account ?
Regards
Marco
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com
Details in attached file
Strange problem cropping up. I chain scripts with command sequences for long
running numerical calculations executed from the initial mintty terminal.
Running from a non administrative session. The form is
---
#!/bin/bash
cd /cygdrive/j/tri60/221-1344c_1.933
mcnp62
they are not. The same problem does not
> arise when starting the same directory name with '/cygdrive/c/'. I
> attach a minimal example program showing the problem. When I run it it
> returns that both ways of naming 'System Volume Information' exist,
> but t
same directory name with '/cygdrive/c/'. I attach a minimal example program
showing the problem. When I run it it returns that both ways of naming 'System
Volume Information' exist, but that 'C:/System Volume Information' can be Read
(which is wrong), while '/cyg
On 2/3/2017 4:09 PM, Rustam wrote:
> I've added an extra / mountpoint in /etc/fstab in order to be able to
> access C: without /cygdrive like this:
>
> none /cygdrive cygdrive binary,posix=0,user 0 0
> none / cygdrive binary,posix=0,user 0 0
>
> It seems t
Greetings, L. A. Walsh!
>> If you want to access Windows path, recommended route lies through the use of
>> cygpath utility to convert native paths to the Cygwin scheme. Et vice versa.
>>
> I wouldn't recommend that -- it's too hard to type:
I didn't say "typing" anywhere.
I did mean permanent
Andrey Repin wrote:
Accessing drive letters directly from inside Cygwin is often
considered a grey area.
How is it grey?
Too much may happen on this border. You have to clearly understand, how Cygwin
interact with other system, to avoid issues.
I.e. if you think you may have
Greetings, Rustam!
> I've added an extra / mountpoint in /etc/fstab in order to be able to
> access C: without /cygdrive like this:
> none /cygdrive cygdrive binary,posix=0,user 0 0
> none / cygdrive binary,posix=0,user 0 0
Only one cygdrive mount is effective.
>
On 02/03/2017 04:10 PM, Rustam wrote:
I've added an extra / mountpoint in /etc/fstab in order to be able to
access C: without /cygdrive like this:
none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive binary,posix=0,user 0 0
It seems to work, I can access the C: drive
I've added an extra / mountpoint in /etc/fstab in order to be able to
access C: without /cygdrive like this:
none /cygdrive cygdrive binary,posix=0,user 0 0
none / cygdrive binary,posix=0,user 0 0
It seems to work, I can access the C: drive with just /c.
But normally an "ls
latform?) from the
>> PE32+ info?:
>> # ls -l bash.exe
>> -rwxr-x---+ 2 TrustedInstaller TrustedInstaller 70656 Oct 14 20:57 bash.exe
>> # file bash.exe
>> bash.exe: PE32+ executable (console) x86-64, for MS Windows
>
> which is exactly the same as Cygwin 64 bash
.exe
> -rwxr-x---+ 2 TrustedInstaller TrustedInstaller 70656 Oct 14 20:57 bash.exe
> # file bash.exe
> bash.exe: PE32+ executable (console) x86-64, for MS Windows
which is exactly the same as Cygwin 64 bash:
$ file /bin/bash /proc/cygdrive/c/WINDOWS/system32/bash
/bin/bash:
in32+.
> from the PE32+ info?:
> 12:08:44pm ingber@lesterX1:/cygdrive/c/Windows/System32# ls -l bash.exe
> -rwxr-x---+ 2 TrustedInstaller TrustedInstaller 70656 Oct 14 20:57
> bash.exe
> 12:08:48pm ingber@lesterX1:/cygdrive/c/Windows/System32# file bash.exe
> bash.exe: PE32+ exe
Lester Ingber wrote:
So, I guess that I should have seen that the Windows 10 Ubuntu bash.exe
is actually written as a 32 bit code (they didn't use the 64-bit code
as on my other true Ubuntu x64 platform?) from the PE32+ info?:
12:08:44pm ingber@lesterX1:/cygdrive/c/Windows/System32#
So, I guess that I should have seen that the Windows 10 Ubuntu bash.exe
is actually written as a 32 bit code (they didn't use the 64-bit code
as on my other true Ubuntu x64 platform?) from the PE32+ info?:
12:08:44pm ingber@lesterX1:/cygdrive/c/Windows/System32# ls -l bash.exe
-rwxr-x-
On 2016-12-21 10:09, Lester Ingber wrote:
> In some older cygwin posts, I see cygwin use of Sysnative for 64-bit
> access to System32 files. In my Cygwin64 installation on my Thinkpad
> Windows 10 x64 Pro PC I cannot see Sysnative at all under cygwin.
> However, for example, using windows opened
In some older cygwin posts, I see cygwin use of Sysnative for 64-bit
access to System32 files. In my Cygwin64 installation on my Thinkpad
Windows 10 x64 Pro PC I cannot see Sysnative at all under cygwin.
However, for example, using windows opened by Malwarebytes I can access
this directory just fi
When the cygdrive prefix is /mnt (via fstab modification) vim swap
file creation malfunctions as following. Shell working directory is ~
in the examples but doesn't seem to matter:
vi -p foo /mnt/d/bar
(swap files created for both)
vi -p /mnt/d/bar foo
(swap file only created for bar)
vi -p
On Dec 18 22:27, Andrey Repin wrote:
> Greetings, Byron!
>
> > Every time I use ssh to a machine I get the fingerprint warnings like
> > it's the first time I've ssh-ed to that machine. I've narrowed it down
> > to have something to do with my `db_hom
Greetings, Byron!
> Every time I use ssh to a machine I get the fingerprint warnings like
> it's the first time I've ssh-ed to that machine. I've narrowed it down
> to have something to do with my `db_home` being set to `/cygdrive/c/%U`
> in `nsswitch.conf`. I have it
ng to do with my `db_home` being set to
> > `/cygdrive/c/%U` in `nsswitch.conf`. I have it set to this value
> > because I want my Cygwin home folder to be the home folder of my
> > computer. Since I'm on an Active Directory network if I set
> > `db_home` to `windows` t
On Dec 18 10:02, Byron wrote:
> Every time I use ssh to a machine I get the fingerprint warnings like
> it's the first time I've ssh-ed to that machine. I've narrowed it down
> to have something to do with my `db_home` being set to `/cygdrive/c/%U`
> in `nsswitch.conf`.
Every time I use ssh to a machine I get the fingerprint warnings like
it's the first time I've ssh-ed to that machine. I've narrowed it down
to have something to do with my `db_home` being set to `/cygdrive/c/%U`
in `nsswitch.conf`. I have it set to this value because I want my
Cyg
Corinna Vinschen writes:
>> I need cygpath to get the system directory (hint: it need not be in
>> C:\Windows\System32) and cygpath delivers that directory with the
>> cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all
>> those special directorie
On Dec 6 15:28, Achim Gratz wrote:
> Corinna Vinschen writes:
> > No offense, but you didn't understand what I mean, it seems.
>
> I did, I think -- but read my request again.
>
> > Don't call cygpath. Just use /proc/cygdrive directly. It's that
> &g
cyg Simple writes:
> Use the $WINDIR variable to find the Windows path and manipulate its
> value to prepend /proc/cygdrive/ and suffix its value with /system32.
> The system32 directory will always be in $WINDIR/sytem32.
That's just as ugly as the solution I have plus that one d
Achim Gratz writes:
> I need cygpath to get the system directory (hint: it need not be in
> C:\Windows\System32) and cygpath delivers that directory with the
> cygdrive prefix and not /proc/cygpath prepended. I wouldn't mind if all
> those special directories would also be av
On 12/6/2015 9:28 AM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> No offense, but you didn't understand what I mean, it seems.
>
> I did, I think -- but read my request again.
>
>> Don't call cygpath. Just use /proc/cygdrive directly. It's tha
Corinna Vinschen writes:
> No offense, but you didn't understand what I mean, it seems.
I did, I think -- but read my request again.
> Don't call cygpath. Just use /proc/cygdrive directly. It's that
> simple. While the cygdrive prefix changes, /proc/cygdrive will
&g
On Dec 6 10:47, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The right thing to do is to change the base-files package to utilize
> > /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive
> > prefix currently in use. If these symlinks under /etc u
Corinna Vinschen writes:
> The right thing to do is to change the base-files package to utilize
> /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive
> prefix currently in use. If these symlinks under /etc used the
> /proc/cygdrive symlink, they would
On 11/26/2015 1:04 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> Achim, any chance to tweak base-file accordingly?
>
> Noted, but it might take a while.
>
That should work. Thanks for listening and working through the problem.
--
cyg Simple
--
Problem reports: http://cygwin.com/
On 11/26/2015 1:04 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> The right thing to do is to change the base-files package to utilize
>> /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive
>> prefix currently in use. If these symlinks un
On Nov 26 19:04, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The right thing to do is to change the base-files package to utilize
> > /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive
> > prefix currently in use. If these symlinks under /etc u
Corinna Vinschen writes:
> The right thing to do is to change the base-files package to utilize
> /proc/cygdrive. It's a vrtual symlink pointing to the actual cygdrive
> prefix currently in use. If these symlinks under /etc used the
> /proc/cygdrive symlink, they would
> Yes I do this all the time. If, for example, C:\cygwin64\etc\fstab
> >>> already exists
> >>> when you run setup-x86_64.exe the first time, setup will use that
> >>> /etc/fstab.
> >>> So all the links will be created during initial installation
t;> exists
>>> when you run setup-x86_64.exe the first time, setup will use that
>>> /etc/fstab.
>>> So all the links will be created during initial installation with / and not
>>> /cygdrive.
>>
>> Just which links we're talking about, yet
t;> when you run setup-x86_64.exe the first time, setup will use that /etc/fstab.
>> So all the links will be created during initial installation with / and not
>> /cygdrive.
>
> Just which links we're talking about, yet again?...
>
find / -type l -exec ls -l {} \; |
t; So all the links will be created during initial installation with / and not
> /cygdrive.
Just which links we're talking about, yet again?...
--
With best regards,
Andrey Repin
Wednesday, November 25, 2015 23:24:47
Sorry for my terrible english...
--
Problem reports:
Andrey Repin sent the following at Wednesday, November 25, 2015 11:39 AM
>On 11/25/2015 10:56 AM, cyg Simple wrote:
>> I find /cygdrive/ just unbearable and I always change it to / after an
>> install. The issue with this is that post install activities will
>> create sym
g initial installation with / and not
/cygdrive.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
On 11/25/2015 10:56 AM, cyg Simple wrote:
> Friends,
>
> I find /cygdrive/ just unbearable and I always change it to / after an
> install. The issue with this is that post install activities will
> create symlinks using /cygdrive moniker so I must go change those if I
> find
Greetings, cyg Simple!
> I find /cygdrive/ just unbearable and I always change it to / after an
> install. The issue with this is that post install activities will
> create symlinks using /cygdrive moniker so I must go change those if I
> find them.
Just which activities?
I have
On 11/25/2015 10:56 AM, cyg Simple wrote:
I find /cygdrive/ just unbearable and I always change it to / after an
install. The issue with this is that post install activities will
create symlinks using /cygdrive moniker so I must go change those if I
find them. Would it be possible for setup
Friends,
I find /cygdrive/ just unbearable and I always change it to / after an
install. The issue with this is that post install activities will
create symlinks using /cygdrive moniker so I must go change those if I
find them. Would it be possible for setup to ask for the value and
setup the
On Thu, Oct 22, 2015 at 7:48 AM, Corinna Vinschen
wrote:
> I could reproduce this and applied a patch which allows to proceed.
>
> However.
>
> The problem was that the SID S-1-0 has a subauthority count of 0, which
> is really weird. S-1-0-0 would be the NULL SID, but while S-1-0 is a
> valid SI
On Oct 21 18:06, Corinna Vinschen wrote:
> On Oct 21 08:24, Barry Roberts wrote:
> > Attached is the strace output.
>
> Thanks.
>
> The culprit are apparently some weird User and Group SIDs.
>
> 34 22501 [main] ls 3428 build_fh_pc: fh 0x180329B20, dev 00C3
>26 22527 [main] ls 3428 st
On Oct 21 08:24, Barry Roberts wrote:
> Attached is the strace output.
Thanks.
The culprit are apparently some weird User and Group SIDs.
34 22501 [main] ls 3428 build_fh_pc: fh 0x180329B20, dev 00C3
26 22527 [main] ls 3428 stat_worker: (\??\M:\install, 0x600039B40,
0x180329B20), fil
1 - 100 of 730 matches
Mail list logo
