Re: symlinks to unlinked but open files should work
Am 03.07.2016, 13:14 Uhr, schrieb Corinna Vinschen:
You don't even need a symlink. This will show the same result:
exec >out1
rm out1
[[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
I noticed that too meanwhile, but I thought you would not need that
information ;)
It's only about the /dev/fd-symlinks, otherwise cygwin seems to be
correct: they don't work anywhere on an open but deleted file:
ln -sf out1 lout1
exec >out1
[[ -w lout1 ]] || echo lout1 not writable-1 1>&2
rm out1
[[ -w lout1 ]] || echo lout1 not writable-2 1>&2
rm lout1
correctly prints the second message.
In Cygwin we move a deleted but still open file out of the way (into
the trash) so the path is incorrect afterwards but even if we wouldn't
do that, the underlying problem can't be solved:
The problem is that a deleted file in Windows can't be opened anymore.
If you translate the above -w into a libc call access
("/dev/fd/1", W_OK) or its Windows equivalent, that call will always
fail on a deleted file. Same for open/CreateFile, etc.
Sorry, but off the top of my head I don't see a feasible workaround for
this problem.
Not a big issue - I don't know any situation this would break except the
above /dev/fd-test.
-Helmut
--
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
Re: symlinks to unlinked but open files should work
On Jul 1 22:40, Helmut Karlowski wrote:
> Cygwin seems to look up a symlink wrong:
>
> When the target-file is unlinked while it is used by a process the file
> still exists and the symlink should point to that file.
>
> Test:
>
> ln -s out1 lout1
> exec >lout1
> rm out1
> [[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
> rm lout1
>
> Only on cygwin it prints the message.
You don't even need a symlink. This will show the same result:
exec >out1
rm out1
[[ -w /dev/fd/1 ]] || echo /dev/fd/1 not writable 1>&2
In Cygwin we move a deleted but still open file out of the way (into
the trash) so the path is incorrect afterwards but even if we wouldn't
do that, the underlying problem can't be solved:
The problem is that a deleted file in Windows can't be opened anymore.
If you translate the above -w into a libc call access
("/dev/fd/1", W_OK) or its Windows equivalent, that call will always
fail on a deleted file. Same for open/CreateFile, etc.
Sorry, but off the top of my head I don't see a feasible workaround for
this problem.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: symlinks to scripts not found in path
On Apr 10 15:51, KARR, DAVID wrote: On my old 32-bit Win7 box running Cygwin 1.7.26, I have an executable script that is intended to be symlinked to and executed as the symlink name. This works fine. On my new 64-bit Win7 box running Cygwin 1.7.29, I created the symlink using ln -s as before. When I try to execute the script through the symlink, it fails to find it in the path. The script itself has the rx bits set. I can execute the script directly, although it doesn't do anything useful. I didn't see anything obvious in the FAQ or obvious searches. Works fine for me: $ uname -rsm CYGWIN_NT-6.3 1.7.29(0.272/5/3) x86_64 $ mkdir a b $ cd a cat x.sh EOF #!/bin/bash echo Hello World EOF $ chmod +x x.sh $ cd ../b $ ln -s ../a/x.sh hello $ ./hello Hello World Did you miss the #! by any chance? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpYORIbtjH2G.pgp Description: PGP signature
RE: symlinks to scripts not found in path
-Original Message- Vinschen Sent: Thursday, April 10, 2014 9:00 AM Subject: Re: symlinks to scripts not found in path On Apr 10 15:51, KARR, DAVID wrote: On my old 32-bit Win7 box running Cygwin 1.7.26, I have an executable script that is intended to be symlinked to and executed as the symlink name. This works fine. On my new 64-bit Win7 box running Cygwin 1.7.29, I created the symlink using ln -s as before. When I try to execute the script through the symlink, it fails to find it in the path. The script itself has the rx bits set. I can execute the script directly, although it doesn't do anything useful. I didn't see anything obvious in the FAQ or obvious searches. Works fine for me: $ uname -rsm CYGWIN_NT-6.3 1.7.29(0.272/5/3) x86_64 $ mkdir a b $ cd a cat x.sh EOF #!/bin/bash echo Hello World EOF $ chmod +x x.sh $ cd ../b $ ln -s ../a/x.sh hello $ ./hello Hello World Did you miss the #! by any chance? Never mind, I had created the symbolic link with a relative path instead of absolute. Once I recreated it correctly, it worked fine. Thanks.
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/16/2011 11:46 AM, Jon Clugston wrote: On Fri, Dec 16, 2011 at 11:20 AM, Andrew DeFariaand...@defaria.com wrote: On 12/15/2011 07:40 PM, Larry Hall (Cygwin) wrote: I'm having difficulty seeing how what you have described could work unless the consumers of these files are looking for symlinks only, which your example above contradicts. And both of the .bashrc files are registering as plain files, so I think you're right that the file system on which they reside is coming into play, assuming the output above is from Cygwin's 'ls'. But even if you had .bashrc and .bashrc.lnk with the former being a UNIX-form of symlink and the latter being the Cygwin one, I'd still expect Cygwin to recognize .bashrc first and only go looking for the .lnk version if it couldn't find that. I would think that Cygwin should see the .lnk version first. No? I guess not. I thought it worked that way before. This would be a performance disaster - forcing a check for 'x.lnk' every time the software tried to access file 'x'. I doubt that it worked that way before. Correct. It did not work this way for the reason you stated. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/15/2011 07:40 PM, Larry Hall (Cygwin) wrote: I'm having difficulty seeing how what you have described could work unless the consumers of these files are looking for symlinks only, which your example above contradicts. And both of the .bashrc files are registering as plain files, so I think you're right that the file system on which they reside is coming into play, assuming the output above is from Cygwin's 'ls'. But even if you had .bashrc and .bashrc.lnk with the former being a UNIX-form of symlink and the latter being the Cygwin one, I'd still expect Cygwin to recognize .bashrc first and only go looking for the .lnk version if it couldn't find that. I would think that Cygwin should see the .lnk version first. No? I guess not. I thought it worked that way before. The output of strace may convince you of that as well. ;-) It might actually work as you describe it though if you can get Cygwin to think that it can't open the former. I could see that being the case if the UNIX symlink was created by a user ID Cygwin didn't recognize, for example. I've backed off to using hardlinks which work on both systems but it doesn't work for directories. -- Andrew DeFaria http://defaria.com Accept that some days you're the pigeon, and some days you're the statue. -- 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
Re: Symlinks and sharing a home directory between Windows and Linux
On Fri, Dec 16, 2011 at 11:20 AM, Andrew DeFaria and...@defaria.com wrote: On 12/15/2011 07:40 PM, Larry Hall (Cygwin) wrote: I'm having difficulty seeing how what you have described could work unless the consumers of these files are looking for symlinks only, which your example above contradicts. And both of the .bashrc files are registering as plain files, so I think you're right that the file system on which they reside is coming into play, assuming the output above is from Cygwin's 'ls'. But even if you had .bashrc and .bashrc.lnk with the former being a UNIX-form of symlink and the latter being the Cygwin one, I'd still expect Cygwin to recognize .bashrc first and only go looking for the .lnk version if it couldn't find that. I would think that Cygwin should see the .lnk version first. No? I guess not. I thought it worked that way before. This would be a performance disaster - forcing a check for 'x.lnk' every time the software tried to access file 'x'. I doubt that it worked that way before. The output of strace may convince you of that as well. ;-) It might actually work as you describe it though if you can get Cygwin to think that it can't open the former. I could see that being the case if the UNIX symlink was created by a user ID Cygwin didn't recognize, for example. I've backed off to using hardlinks which work on both systems but it doesn't work for directories. -- Andrew DeFaria http://defaria.com Accept that some days you're the pigeon, and some days you're the statue. -- 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 -- 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
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/14/2011 2:32 PM, Andrew DeFaria wrote: On 12/14/2011 12:14 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: Might CYGWIN=winsymlinks help? http://cygwin.com/cygwin-ug-net/using-cygwinenv.html I don't see how. I think that I need the .lnk portion of the file. It's not clear to me from that link's description that setting winsymlinks gives me .lnk. Hmmm... Just tested. Ah yes! The winsymlinks seems to do the trick! Thanks! More: http://cygwin.com/faq/faq-nochunks.html#faq.using.symlinkstoppedworking http://cygwin.com/faq/faq-nochunks.html#faq.api.symlinks Thanks for the references... I'm not sure this is working as well as I had hoped (or remembered). I think the question boils down to, given a Unix symlink of say .bash_login and a Cygwin symlink of say .bash_login.lnk, which does Cygwin read when logging it? I would have hoped that Cygwin would always see the .lnk file whereas Unix would see the regular symlink. That's how I thought this worked before. But it doesn't seem to be working that way. In fact I see: $ ls -l .bash* -rw-r--r-- 1 adefaria clearusers 7179 Dec 15 15:35 .bash_history -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bash_login -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bash_login -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bashrc -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bashrc When I login bash see the Unix formated .bash_login symlink and chokes. I can remove this Unix symlink from the Unix side and log in with bash again and it works. If I remake the symlink on the Unix side it fails! :-( I don't remember this being a problem before. I fear this is a Samba config thing... Note: CYGWIN has winsymlinks in it... -- Andrew DeFaria http://defaria.com Law of Probability Dispersal: Whatever it is that hits the fan will not be evenly distributed. -- 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
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/15/2011 6:47 PM, Andrew DeFaria wrote: On 12/14/2011 2:32 PM, Andrew DeFaria wrote: On 12/14/2011 12:14 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: Might CYGWIN=winsymlinks help? http://cygwin.com/cygwin-ug-net/using-cygwinenv.html I don't see how. I think that I need the .lnk portion of the file. It's not clear to me from that link's description that setting winsymlinks gives me .lnk. Hmmm... Just tested. Ah yes! The winsymlinks seems to do the trick! Thanks! More: http://cygwin.com/faq/faq-nochunks.html#faq.using.symlinkstoppedworking http://cygwin.com/faq/faq-nochunks.html#faq.api.symlinks Thanks for the references... I'm not sure this is working as well as I had hoped (or remembered). I think the question boils down to, given a Unix symlink of say .bash_login and a Cygwin symlink of say .bash_login.lnk, which does Cygwin read when logging it? I would have hoped that Cygwin would always see the .lnk file whereas Unix would see the regular symlink. That's how I thought this worked before. But it doesn't seem to be working that way. In fact I see: $ ls -l .bash* -rw-r--r-- 1 adefaria clearusers 7179 Dec 15 15:35 .bash_history -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bash_login -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bash_login -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bashrc -rw-r--r-- 1 adefaria clearusers 29 Dec 15 14:36 .bashrc When I login bash see the Unix formated .bash_login symlink and chokes. I can remove this Unix symlink from the Unix side and log in with bash again and it works. If I remake the symlink on the Unix side it fails! :-( I don't remember this being a problem before. I fear this is a Samba config thing... Note: CYGWIN has winsymlinks in it... I'm having difficulty seeing how what you have described could work unless the consumers of these files are looking for symlinks only, which your example above contradicts. And both of the .bashrc files are registering as plain files, so I think you're right that the file system on which they reside is coming into play, assuming the output above is from Cygwin's 'ls'. But even if you had .bashrc and .bashrc.lnk with the former being a UNIX-form of symlink and the latter being the Cygwin one, I'd still expect Cygwin to recognize .bashrc first and only go looking for the .lnk version if it couldn't find that. The output of strace may convince you of that as well. ;-) It might actually work as you describe it though if you can get Cygwin to think that it can't open the former. I could see that being the case if the UNIX symlink was created by a user ID Cygwin didn't recognize, for example. -- Larry _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/14/2011 01:33 PM, Andrew DeFaria wrote: I like having only one home directory. It's extremely convenient to have the same settings and the like both when on Cygwin and when on Linux. Often home directories are on NAS's and the like and served out via smb. Somewhere along the line Cygwin's symlink implementation changed again. It used to be that symlinks ended in .lnk, which was sort of a pain but workable. One nice thing is that they didn't clash with Linux symlinks. A Cygwin symlink is not the same as a Linux symlink and so you could have: $ ln -s a_file.txt link1 # in Cygwin $ ln -s a_file.txt link1 # in Linux and you'd end up having a symlink with the same name, link1, pointing to the same file from either Cygwin or Linux. This is because the Linux symlink is named just link1 and the Cygwin symlink is named link1.txt. But now Cygwin names its symlink link1. When you then log into Linux and try to access that link it doesn't work. Where this is happening for me is that I put all of my rc files under ~/.rc and then I symlink them to ~ as appropriate. So, for example I have a ~/.rc/inputrc. I then symlink them to ~/.inputrc. Under the old scenario I'd get a ~/.inputrc.lnk for Cygwin and a ~/.inputrc on Linux. Under the new scenario I get a clash. Is there any way around this? Would a hard link work instead? -Jeremy -- 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
RE: Symlinks and sharing a home directory between Windows and Linux
Jeremy Bopp sent the following at Wednesday, December 14, 2011 3:01 PM On 12/14/2011 01:33 PM, Andrew DeFaria wrote: I like having only one home directory. It's extremely convenient to have the same settings and the like both when on Cygwin and when on Linux. Often home directories are on NAS's and the like and served out via smb. Somewhere along the line Cygwin's symlink implementation changed again. It used to be that symlinks ended in .lnk, which was sort of a pain but workable. One nice thing is that they didn't clash with Linux symlinks. A Cygwin symlink is not the same as a Linux symlink and so you could have: $ ln -s a_file.txt link1 # in Cygwin $ ln -s a_file.txt link1 # in Linux and you'd end up having a symlink with the same name, link1, pointing to the same file from either Cygwin or Linux. This is because the Linux symlink is named just link1 and the Cygwin symlink is named link1.txt. But now Cygwin names its symlink link1. When you then log into Linux and try to access that link it doesn't work. Where this is happening for me is that I put all of my rc files under ~/.rc and then I symlink them to ~ as appropriate. So, for example I have a ~/.rc/inputrc. I then symlink them to ~/.inputrc. Under the old scenario I'd get a ~/.inputrc.lnk for Cygwin and a ~/.inputrc on Linux. Under the new scenario I get a clash. Is there any way around this? Would a hard link work instead? Might CYGWIN=winsymlinks help? http://cygwin.com/cygwin-ug-net/using-cygwinenv.html More: http://cygwin.com/faq/faq-nochunks.html#faq.using.symlinkstoppedworking http://cygwin.com/faq/faq-nochunks.html#faq.api.symlinks Good luck. - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- 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
Re: Symlinks and sharing a home directory between Windows and Linux
On 12/14/2011 12:14 PM, Buchbinder, Barry (NIH/NIAID) [E] wrote: Might CYGWIN=winsymlinks help? http://cygwin.com/cygwin-ug-net/using-cygwinenv.html I don't see how. I think that I need the .lnk portion of the file. It's not clear to me from that link's description that setting winsymlinks gives me .lnk. Hmmm... Just tested. Ah yes! The winsymlinks seems to do the trick! Thanks! More: http://cygwin.com/faq/faq-nochunks.html#faq.using.symlinkstoppedworking http://cygwin.com/faq/faq-nochunks.html#faq.api.symlinks Thanks for the references... -- Andrew DeFaria http://defaria.com Never argue with a fool; he will soon beat you with his experience. -- 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
Re: symlinks: converting Windows shortcuts to cygwin style
On Mar 5 09:11, Buchbinder, Barry (NIH/NIAID) [E] wrote: Does someone have a script that converts symbolic links from Windows shortcuts with a special header and the R/O attribute set to plain files with a magic number, a path and the system attribute set. (See (no)winsymlinks in http://cygwin.com/cygwin-ug-net/using-cygwinenv.html.) Something like that for lnk in $(find . -xdev -type l) do tgt=$(readlink $lnk) rm -f $lnk ln -s $tgt $lnk done Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
RE: symlinks: converting Windows shortcuts to cygwin style
Corinna Vinschen sent the following at Friday, March 05, 2010 10:33 AM On Mar 5 09:11, Buchbinder, Barry (NIH/NIAID) [E] wrote: Does someone have a script that converts symbolic links from Windows shortcuts with a special header and the R/O attribute set to plain files with a magic number, a path and the system attribute set. (See (no)winsymlinks in http://cygwin.com/cygwin-ug-net/using-cygwinenv.html.) Something like that for lnk in $(find . -xdev -type l) do tgt=$(readlink $lnk) rm -f $lnk ln -s $tgt $lnk done Thank you. -- 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
Re: symlinks show .exe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Vincent Rivière on 10/4/2009 6:21 AM: $ ln -s /bin/ls lls $ ls -l lls lrwxrwxrwx 1 vincent cygwin 11 Oct 4 14:13 lls - /bin/ls.exe Do you agree this is a bug and it should be fixed ? I'm not sure whether I agree that it is a bug. But I already know that the existing 1.7 build of coreutils needs some TLC with .exe magic, once I can get enough time to focus on it. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrIrh4ACgkQ84KuGfSFAYCbdACghQ5ijPUrAdIFwzGO2L3FLxcx KOoAniNf7BUzJbq4sOwTq7C3K2Fat9XB =kH1z -END PGP SIGNATURE- -- 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
Re: symlinks show .exe
2009/10/5 Vincent Rivière vincent.rivi...@freesbee.fr: Do you agree this is a bug and it should be fixed ? I've got nothing to do with the code, but I am an interested observer. In my experience, it should be possible to create symlinks to any arbitrary target, regardless of whether it actually exists or not. Therefore, if I create a symlink to /bin/ls then I'd expect that to be the content of the symlink - the automatic behaviour of rewriting it to /bin/ls.exe is unexpected and therefore probably incorrect according to some standard somewhere. Perhaps the 'shortcut' of omitting the .exe extension is getting in the way here - it's preventing unambiguous identification of the symlink target. But maybe I misunderstand the scope of symlinks and something somewhere says the system can rewrite them to point at valid targets if it wishes? -- David. -- 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
Re: symlinks show .exe
On Oct 5 09:12, David Antliff wrote: 2009/10/5 Vincent Rivière vincent.rivi...@freesbee.fr: Do you agree this is a bug and it should be fixed ? I've got nothing to do with the code, but I am an interested observer. In my experience, it should be possible to create symlinks to any arbitrary target, regardless of whether it actually exists or not. Therefore, if I create a symlink to /bin/ls then I'd expect that to be the content of the symlink - the automatic behaviour of rewriting it to /bin/ls.exe is unexpected and therefore probably incorrect according to some standard somewhere. The Cygwin symlink(2) call does not add the .exe suffix, neither in Cygwin 1.5, nor in Cygwin 1.7. It looks like a feature of the ln(1) tool from the Cygwin 1.5 coreutils, AFAICS. ln(1) from the Cygwin 1.7 coreutils does also not add a .exe suffix. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
Re: symlinks show .exe
David Antliff wrote: In my experience, it should be possible to create symlinks to any arbitrary target, regardless of whether it actually exists or not. Therefore, if I create a symlink to /bin/ls then I'd expect that to be the content of the symlink - the automatic behaviour of rewriting it to /bin/ls.exe is unexpected and therefore probably incorrect according to some standard somewhere. I totally agree. The symlink target should be stored as is without further interpretation. The example of non existing target is good. An this gives me an idea: $ mv /bin/ls /bin/ls.bak $ ln -s /bin/ls lls $ mv /bin/ls.bak /bin/ls $ ls -l lls lrwxrwxrwx 1 vincent cygwin 7 Oct 4 22:19 lls - /bin/ls $ ./lls The symlink looks good and it works ;-) -- Vincent Rivière -- 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
Re: symlinks show .exe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 10/4/2009 2:19 PM: The Cygwin symlink(2) call does not add the .exe suffix, neither in Cygwin 1.5, nor in Cygwin 1.7. It looks like a feature of the ln(1) tool from the Cygwin 1.5 coreutils, AFAICS. Yes, the 1.5 ln(1) had some .exe magic, because cygwin1.dll 1.5 did not always handle symlinks gracefully if the .exe was not present. ln(1) from the Cygwin 1.7 coreutils does also not add a .exe suffix. Probably because cygwin 1.7 handles .exe better. I disabled some of the .exe magic when porting coreutils to 1.7 (perhaps too much, though, based on reports of cp not doing enough .exe magic). - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrJMXUACgkQ84KuGfSFAYDENwCfUk3RH5F38TtizL1Roo5Ygxkp aIsAniyJ79iLbAHHPXpImJQ06kq9lDVE =Q8L1 -END PGP SIGNATURE- -- 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
Re: Symlinks don't work in python???
Steve, On Tue, Apr 19, 2005 at 08:48:16AM -0400, Jason Tishler wrote: You can workaround the problem by defining PYTHONCASEOK: $ PYTHONCASEOK= python -c 'import bar' $ I will work with the Python developers to try to come up with a better long term solution. I have found the long term solution to this problem: http://sf.net/tracker/index.php?func=detailaid=1197318group_id=5470atid=305470 The solution was actually much easier than I thought -- it just makes Cygwin use the Mac OS X case checking function (i.e, case_ok()) instead of a modified Window's version. The next Cygwin Python package will have the above mentioned patch applied. Thanks for helping to uncover this bug. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Jason - Looks like just the right fix. Thanks for all the good work. - Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Steve, On Fri, Apr 08, 2005 at 01:39:23PM -0400, Steve Ward wrote: (3) Thinking that the realpath bug might be a key to the python import-thru-symlinks problem, I ran a simple test on recent cygwin/python combinations, finding: Cygwin version Python version realpath Import 1.5.xx: 2.yy:Works? Works? -- -- -- 1.5.14 2.4NO NO 1.5.13 2.3.4 YES NO 1.5.14 2.3.4 YES NO 1.5.12 2.4NO YES I question the results of the last test case above. I get the following: $ uname -a CYGWIN_NT-5.1 stella 1.5.12(0.116/4/2) 2004-11-10 08:34 ... $ python -V Python 2.4 $ ls -l total 1 lrwxrwxrwx1 jt None6 Apr 19 08:24 bar.py - foo.py -rw-r--r--1 jt None 24 Apr 18 20:13 foo.py $ python -c 'import bar' Traceback (most recent call last): File string, line 1, in ? ImportError: No module named bar See my next post... Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Steve, On Fri, Apr 15, 2005 at 10:12:56PM -0400, Jason Tishler wrote: On Fri, Apr 15, 2005 at 03:54:37PM -0400, Steve Ward wrote: Can you try my failing experiment (symlink bar.py to file foo.py in same directory)? I was able reproduce your problem on my way out of work today. It seems using a different name for the symlink may cause the trouble... I have no idea why. Can you strace the issue and report back to the list? If not, then I will try when I'm back at work on Monday. AFAICT, symlinking bar.py to foo.py never worked or at least since case-insensitive file system support was added to Python in 2/2001: http://www.amk.ca/python/2.1/index.html#SECTION000100 The problem is Cygwin specific code is invoked during imports to make sure one imports a module using the same case as the file stored in the file system. For example, foo will match foo.py but not FoO.py, etc. When you import bar (i.e., bar.py) which is symlinked to foo.py the case checking code fails (because bar != foo) and the module is skipped. You can workaround the problem by defining PYTHONCASEOK: $ PYTHONCASEOK= python -c 'import bar' $ I will work with the Python developers to try to come up with a better long term solution. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
On Tue, 19 Apr 2005, Jason Tishler wrote: Steve, On Fri, Apr 15, 2005 at 10:12:56PM -0400, Jason Tishler wrote: On Fri, Apr 15, 2005 at 03:54:37PM -0400, Steve Ward wrote: Can you try my failing experiment (symlink bar.py to file foo.py in same directory)? I was able reproduce your problem on my way out of work today. It seems using a different name for the symlink may cause the trouble... I have no idea why. Can you strace the issue and report back to the list? If not, then I will try when I'm back at work on Monday. AFAICT, symlinking bar.py to foo.py never worked or at least since case-insensitive file system support was added to Python in 2/2001: http://www.amk.ca/python/2.1/index.html#SECTION000100 Why not use the built-in Cygwin case checking feature with CYGWIN=check_case:strict? The problem is Cygwin specific code is invoked during imports to make sure one imports a module using the same case as the file stored in the file system. For example, foo will match foo.py but not FoO.py, etc. When you import bar (i.e., bar.py) which is symlinked to foo.py the case checking code fails (because bar != foo) and the module is skipped. Ouch. It should be checking against the resolved Win32 filename instead. See below. You can workaround the problem by defining PYTHONCASEOK: $ PYTHONCASEOK= python -c 'import bar' $ I will work with the Python developers to try to come up with a better long term solution. The way Cygwin does it internally is get a directory entry using a given Win32 filename, and then compare the case of the filename with that of the directory entry. The first part ensures that the filename can only refer to the same file, and this happens after symlink resolution, so if bar.py is a symlink to FoO.py, and the file on disk is fOo.py, the latter check will fail. HTH, Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
On Tue, Apr 19, 2005 at 10:27:08AM -0400, Igor Pechtchanski wrote: On Tue, 19 Apr 2005, Jason Tishler wrote: On Fri, Apr 15, 2005 at 10:12:56PM -0400, Jason Tishler wrote: On Fri, Apr 15, 2005 at 03:54:37PM -0400, Steve Ward wrote: Can you try my failing experiment (symlink bar.py to file foo.py in same directory)? I was able reproduce your problem on my way out of work today. It seems using a different name for the symlink may cause the trouble... I have no idea why. Can you strace the issue and report back to the list? If not, then I will try when I'm back at work on Monday. AFAICT, symlinking bar.py to foo.py never worked or at least since case-insensitive file system support was added to Python in 2/2001: http://www.amk.ca/python/2.1/index.html#SECTION000100 Why not use the built-in Cygwin case checking feature with CYGWIN=check_case:strict? Please do not use this option unless it is absolutely necessary or if you actually desire a slowdown for every operation which involves a filename. Yes, Igor, I can keep this up all day, if you'd like. Now, you respond with how unbelievably useful it is and I'll respond with how much overhead this introduces and how often the option is broken in subtle ways because neither Corinna nor I care for it. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Jason - Thanks for all the good work. The PYTHONCASEOK workaround indeed seems to solve the problem. From your description, it seems that the trouble is that the real name (the name of the symlink target) is used rather than the name of the symlink; I should be able to circumvent naming problems, including case problems on Windows, via appropriately-named symlinks. It seems that this should be a straightforward fix to the case-insensitive code hack ... but, of course, I haven't looked at that code. Again, thanks for the insight! - Steve Date: Tue, 19 Apr 2005 08:48:16 -0400 From: Jason Tishler [EMAIL PROTECTED] Mail-Followup-To: cygwin@cygwin.com, [EMAIL PROTECTED] Content-Disposition: inline X-Scanned-By: MIMEDefang 2.42 X-Scan-Signature: e350b74e66957c09d06207840ae4bf8e X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on k2.csail.mit.edu X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.0.2 Steve, On Fri, Apr 15, 2005 at 10:12:56PM -0400, Jason Tishler wrote: On Fri, Apr 15, 2005 at 03:54:37PM -0400, Steve Ward wrote: Can you try my failing experiment (symlink bar.py to file foo.py in same directory)? I was able reproduce your problem on my way out of work today. It seems using a different name for the symlink may cause the trouble... I have no idea why. Can you strace the issue and report back to the list? If not, then I will try when I'm back at work on Monday. AFAICT, symlinking bar.py to foo.py never worked or at least since case-insensitive file system support was added to Python in 2/2001: http://www.amk.ca/python/2.1/index.html#SECTION000100 The problem is Cygwin specific code is invoked during imports to make sure one imports a module using the same case as the file stored in the file system. For example, foo will match foo.py but not FoO.py, etc. When you import bar (i.e., bar.py) which is symlinked to foo.py the case checking code fails (because bar != foo) and the module is skipped. You can workaround the problem by defining PYTHONCASEOK: $ PYTHONCASEOK= python -c 'import bar' $ I will work with the Python developers to try to come up with a better long term solution. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Jason, RE: Sorry, but I cannot reproduce the above problem with the latest snapshot: $ uname -a CYGWIN_NT-5.1 gelpdevjt022 1.5.15s(0.126/4/2) 20050408 16:35:04 ... $ python -V Python 2.4 $ ls -l total 0 lrwxrwxrwx1 jtishler Domain U 11 Apr 11 10:14 foo.py - /tmp/foo.py $ python -c 'import foo' $ Jason That's curious, given that: uname -a CYGWIN_NT-5.1 ward 1.5.15s(0.126/4/2) 20050408 16:35:04 i686 unknown unknown Cygwin python -V Python 2.4 ls -l total 2 lrwxrwxrwx 1 ward None 6 Apr 15 15:31 bar.py - foo.py -rwxrwxrwx 1 ward None 34 Apr 15 15:31 foo.py python -c 'import foo' This is file foo.py. python -c 'import bar' Traceback (most recent call last): File string, line 1, in ? ImportError: No module named bar is reproducible on multiple machines here. HOWEVER, when I repeat your experiment more precisely: uname -a CYGWIN_NT-5.1 ward 1.5.15s(0.126/4/2) 20050408 16:35:04 i686 unknown unknown Cygwin python -V Python 2.4 ls -l total 1 lrwxrwxrwx 1 ward None 11 Apr 15 15:43 foo.py - /tmp/foo.py python -c 'import foo' This is file foo.py. all seems OK. Can you try my failing experiment (symlink bar.py to file foo.py in same directory)? It seems using a different name for the symlink may cause the trouble... I have no idea why. Thanks, Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Steve, On Fri, Apr 15, 2005 at 03:54:37PM -0400, Steve Ward wrote: Can you try my failing experiment (symlink bar.py to file foo.py in same directory)? I was able reproduce your problem on my way out of work today. It seems using a different name for the symlink may cause the trouble... I have no idea why. Can you strace the issue and report back to the list? If not, then I will try when I'm back at work on Monday. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
Steve, On Wed, Apr 06, 2005 at 05:04:52PM -0400, Steve Ward wrote: I just upgraded to cygwin 1.5.14 from 1.5.12, and python (version 2.4 in both cases) stopped being able to import thru symlinks. Test case: in a directory containing a symlink to foo.py, python import foo complains no module named foo.py; if I copy the file to ., it imports fine. Both worked in previous releases of cygwin. See below... On Fri, Apr 08, 2005 at 02:45:33PM -0400, Steve Ward wrote: Joerg - thanks for the suggestion. I tried the latest cygwin1.dll snapshot; both bugs still show up. Sorry, but I cannot reproduce the above problem with the latest snapshot: $ uname -a CYGWIN_NT-5.1 gelpdevjt022 1.5.15s(0.126/4/2) 20050408 16:35:04 ... $ python -V Python 2.4 $ ls -l total 0 lrwxrwxrwx1 jtishler Domain U 11 Apr 11 10:14 foo.py - /tmp/foo.py $ python -c 'import foo' $ Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
RE: I just upgraded to cygwin 1.5.14 from 1.5.12, and python (version 2.4 in both cases) stopped being able to import thru symlinks. Test case: in a directory containing a symlink to foo.py, python import foo complains no module named foo.py; if I copy the file to ., it imports fine. Both worked in previous releases of cygwin. Similarly, putting symlinks in site-packages no longer works. Has some change to cygwin's handling of symlinks (since 1.5.12) caused this problem? Further exploration of the import-thru-symlink bug in Cygwin python reveals that: (1) Despite the problem with imports, most os.path utilities (exists, isfile, islink, isdir) work. (2) The one execption I've found is realpath, which fails in python 2.4 under cygwin. It returns a path to the symlink, not to the target file. (3) Thinking that the realpath bug might be a key to the python import-thru-symlinks problem, I ran a simple test on recent cygwin/python combinations, finding: Cygwin version Python version realpath Import 1.5.xx: 2.yy:Works? Works? -- -- -- 1.5.14 2.4NO NO 1.5.13 2.3.4 YES NO 1.5.14 2.3.4 YES NO 1.5.12 2.4NO YES Neither bug shows up under Linux. Interestingly, the realpath and symlink bugs don't correlate: realpath seems broken in Cygwin python 2.4, independently of the cygwin package version, while the import bug shows up in either python version under cygwin packages since 1.5.13. Its possible that the problems are python bugs, but they seem cygwin specific. The import bug breaks several installations I use (which configure python via symlinks in site-packages, which no longer works under cygwin); has nobody else run into this problem? I suppose its possible that the bugs are triggered by something peculiar to the environment of my machines... Any ideas? - Steve Ward -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
[snip] (3) Thinking that the realpath bug might be a key to the python import-thru-symlinks problem, I ran a simple test on recent cygwin/python combinations, finding: Cygwin version Python version realpath Import 1.5.xx: 2.yy:Works? Works? -- -- -- 1.5.14 2.4NO NO 1.5.13 2.3.4 YES NO 1.5.14 2.3.4 YES NO 1.5.12 2.4NO YES Neither bug shows up under Linux. Interestingly, the realpath and symlink bugs don't correlate: realpath seems broken in Cygwin python 2.4, independently of the cygwin package version, while the import bug shows up in either python version under cygwin packages since 1.5.13. Its possible that the problems are python bugs, but they seem cygwin specific. Steve, try also the latest cygwin snapshot. At least in 1.5.14 was a bug concerning path conversion posix - Windows, when a symlink was involved. It manifests in at least in cygpath, but is fixed meanwhile and might also have influence on your test cases. - Jörg -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Symlinks don't work in python???
RE: (3) Thinking that the realpath bug might be a key to the python import-thru-symlinks problem, I ran a simple test on recent cygwin/python combinations, finding: Cygwin version Python version realpath Import 1.5.xx: 2.yy:Works? Works? -- -- -- 1.5.14 2.4NO NO 1.5.13 2.3.4 YES NO 1.5.14 2.3.4 YES NO 1.5.12 2.4NO YES Neither bug shows up under Linux. Interestingly, the realpath and symlink bugs don't correlate: realpath seems broken in Cygwin python 2.4, independently of the cygwin package version, while the import bug shows up in either python version under cygwin packages since 1.5.13. Its possible that the problems are python bugs, but they seem cygwin specific. Steve, try also the latest cygwin snapshot. At least in 1.5.14 was a bug concerning path conversion posix - Windows, when a symlink was involved. It manifests in at least in cygpath, but is fixed meanwhile and might also have influence on your test cases. - Joerg Joerg - thanks for the suggestion. I tried the latest cygwin1.dll snapshot; both bugs still show up. - Steve -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: symlinks
Thanks all it works now. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
