mintty question (file name too long)
I installed mintty (put the js file in the /bin folder, created a short cut, started the shell from that short cut), but I'm not able to use ssh, and when I type ls into my cygdrive directory, I get the following error. (Everything works fine from Cygwin's interface, of course) Error: Current working directory is a virtual Cygwin directory. Can't start native Windows application from here. bash: /cygdrive/c/WINDOWS/system32/ls: File name too long bash-3.2$ ls -al Error: Current working directory is a virtual Cygwin directory. Can't start native Windows application from here. bash: /cygdrive/c/WINDOWS/system32/ls: File name too long bash-3.2$ * I would like to use Mintty interface instead of Windows' and have access to the same commands and tools. -- 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: mintty question (file name too long)
2009/12/20 Rogelio:
I installed mintty (put the js file in the /bin folder, created a
short cut, started the shell from that short cut)
You don't need to put the js file in the /bin folder. Its only purpose
is to create a mintty shortcut for you.
However, the easiest way to install mintty is through Cygwin's
setup.exe, where it appears in the Shells category. This will also
automatically create a suitable mintty shortcut under Cygwin in the
start menu.
but I'm not able to
use ssh, and when I type ls into my cygdrive directory, I get the
following error. (Everything works fine from Cygwin's interface, of
course)
Error: Current working directory is a virtual Cygwin directory.
Can't start native Windows application from here.
bash: /cygdrive/c/WINDOWS/system32/ls: File name too long
bash-3.2$ ls -al
Error: Current working directory is a virtual Cygwin directory.
Can't start native Windows application from here.
bash: /cygdrive/c/WINDOWS/system32/ls: File name too long
bash-3.2$
I don't know what version of 'ls' you're picking up there, but in any
case it looks as if bash is being invoked as a non-login shell. That
means that /etc/profile isn't being executed, hence you don't get the
standard Cygwin prompt and the Cygwin /bin directory isn't added to
the path.
To ensure that bash is invoked as a login shell, mintty needs to be
invoked with a single dash ('-') as parameter, i.e. the shortcut
target needs to be something like: C:\cygwin\bin\mintty.exe -.
Andy
--
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: mintty question (file name too long)
FWIW, I ended up going with PuTTYcyg http://code.google.com/p/puttycyg/ It was super easy to set up (and I needed something fast). Thanks for the other suggestions, and I will test those out when I get some more time! -- 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
file name too long
Hello, I updated my cygwin installation to 1.5.25-15 but I'm still getting 'file name too long' errors when trying to extract a .tgz archive that contains some really long pathnames. Here is an example of one of the errors: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. Interestingly, even some of the files that 'tar' can extract, 'ls' returns an error when I try to see the contents of the directory: ls: cannot access S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file0.fa: File name too long I found this (http://www.cygwin.com/ml/cygwin-developers/2008-01/msg0.html) discussion of what seems to be the same problem that I am having. So, was a fix ever implemented? Is there a workaround to this problem other than installing Linux? Thank you for your help, Paul -- Paul Cantalupo Research Specialist/Systems Programmer 559 Crawford Hall Department of Biological Sciences University of Pittsburgh Pittsburgh, PA 15260 Work: 412-624-4687 Fax: 412-624-4759 -- 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: file name too long
Paul Cantalupo wrote: Hello, I updated my cygwin installation to 1.5.25-15 but I'm still getting 'file name too long' errors when trying to extract a .tgz archive that contains some really long pathnames. Here is an example of one of the errors: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. Interestingly, even some of the files that 'tar' can extract, 'ls' returns an error when I try to see the contents of the directory: ls: cannot access S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file0.fa: File name too long I found this (http://www.cygwin.com/ml/cygwin-developers/2008-01/msg0.html) discussion of what seems to be the same problem that I am having. So, was a fix ever implemented? Is there a workaround to this problem other than installing Linux? Yes, it was implemented for the upcoming Cygwin 1.7 release, now in release testing: http://cygwin.com/ml/cygwin-announce/2009-02/msg00018.html -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: file name too long
On Tue, 24 Feb 2009, Paul Cantalupo hey, I remembers to expunge this! wrote: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. I have a vague memory that the limit includes the current directory path. Anyone else know whether that's true or not? What's the current directory name when running that? If you add the length of the current directory name, plus one for the / separator, plus the length of the path above, is it more than 254? Is there a workaround to this problem other than installing Linux? When the problem can be helped with a shorter directory name, I use the subst Windows command to map the directory to a drive letter. That shortens the directory name from whatever to 2. For example, M: is one letter that I leave unused, and /mnt is my value instead of /cygdrive. So, as an untested example from Windows Server 2003: /mnt/c/WINDOWS/system32/subst M: 'c:\long\path name\goes here' pushd /mnt/m [do my work here] popd /mnt/c/WINDOWS/system32/subst M: /d# unmap the drive letter -- Tim McDaniel, t...@panix.com -- 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: file name too long
On Tue, Feb 24, 2009 at 4:27 PM, Tim McDaniel t...@panix.com wrote: On Tue, 24 Feb 2009, Paul Cantalupo hey, I remembers to expunge this! wrote: tar: S1172_Spanish_Protin_Total_Nucleic_Acid/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_HGblast/S1172_Spanish_Protin_Total_Nucleic_Acid.fa.cdhit_out.masked.goodSeq_file7.HGblast.out: Cannot open: File name too long This name is only 201 chars long; I thought Windows max file length was 255. I have a vague memory that the limit includes the current directory path. Anyone else know whether that's true or not? The issue is definitely an issue with the full path length. There may also be a max filename length, but I have not come across it. Is there a workaround to this problem other than installing Linux? Since your just trying to extract a tar file, create a directory c:/a then cd into it and try to extract from there. We use that trick fairly often. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer First 99 Days Litigation White Paper - http://www.norcrossgroup.com/forms/whitepapers/99%20Days%20whitepaper.pdf The Norcross Group The Intersection of Evidence Technology http://www.norcrossgroup.com -- 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: File name too long issues while using snv (subversion)
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Christopher Faylor Sent: Wednesday, February 11, 2009 1:03 To: cygwin@cygwin.com Subject: Re: File name too long issues while using snv (subversion) On Wed, Feb 11, 2009 at 12:49:10AM -0500, Jason Pyeron wrote: How can I make use of http://www.cygwin.com/ml/cygwin-developers/2008-03/msg0.html? You obviously haven't been paying attention to Corinna's Cygwin 1.7 announcements. No, I do not track most emails on this list, as time does not permit. Would you be refering to http://www.cygwin.com/ml/cygwin-apps/2008-07/msg00060.html (Does not directly mention long file paths/names, but does mention utf8) If so, when I run the install will all of my existing cygwin apps still work? Or is this a long and complicated process? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: File name too long issues while using snv (subversion)
On Feb 11 09:32, Jason Pyeron wrote: -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Christopher Faylor Sent: Wednesday, February 11, 2009 1:03 To: cygwin@cygwin.com Subject: Re: File name too long issues while using snv (subversion) On Wed, Feb 11, 2009 at 12:49:10AM -0500, Jason Pyeron wrote: How can I make use of http://www.cygwin.com/ml/cygwin-developers/2008-03/msg0.html? You obviously haven't been paying attention to Corinna's Cygwin 1.7 announcements. No, I do not track most emails on this list, as time does not permit. Would you be refering to http://www.cygwin.com/ml/cygwin-apps/2008-07/msg00060.html (Does not directly mention long file paths/names, but does mention utf8) No, he's referring to http://cygwin.com/ml/cygwin/2008-12/msg00225.html http://cygwin.com/ml/cygwin/2008-12/msg00468.html http://cygwin.com/ml/cygwin/2008-12/msg00583.html http://cygwin.com/ml/cygwin/2009-01/msg00631.html http://cygwin.com/ml/cygwin/2009-01/msg00818.html http://cygwin.com/ml/cygwin/2009-02/msg00222.html Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: File name too long issues while using snv (subversion)
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Wednesday, February 11, 2009 9:46 To: cygwin@cygwin.com Subject: Re: File name too long issues while using snv (subversion) On Feb 11 09:32, Jason Pyeron wrote: -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Christopher Faylor Sent: Wednesday, February 11, 2009 1:03 To: cygwin@cygwin.com Subject: Re: File name too long issues while using snv (subversion) On Wed, Feb 11, 2009 at 12:49:10AM -0500, Jason Pyeron wrote: How can I make use of http://www.cygwin.com/ml/cygwin-developers/2008-03/msg0.html? You obviously haven't been paying attention to Corinna's Cygwin 1.7 announcements. No, I do not track most emails on this list, as time does not permit. Would you be refering to http://www.cygwin.com/ml/cygwin-apps/2008-07/msg00060.html (Does not directly mention long file paths/names, but does mention utf8) No, he's referring to http://cygwin.com/ml/cygwin/2008-12/msg00225.html http://cygwin.com/ml/cygwin/2008-12/msg00468.html http://cygwin.com/ml/cygwin/2008-12/msg00583.html http://cygwin.com/ml/cygwin/2009-01/msg00631.html http://cygwin.com/ml/cygwin/2009-01/msg00818.html http://cygwin.com/ml/cygwin/2009-02/msg00222.html Great. I have just installed it over 1.5 letting the setup choose the packages. I am no longer getting the file name too long error. I may be immagining, but file IO seems much faster. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: File name too long issues while using snv (subversion)
On Feb 11 10:01, Jason Pyeron wrote: http://cygwin.com/ml/cygwin/2009-02/msg00222.html Great. I have just installed it over 1.5 letting the setup choose the packages. I am no longer getting the file name too long error. I may be immagining, but file IO seems much faster. I hope so. Please don't forget to read the new User's GUide at http://cygwin.com/1.7/cygwin-ug-net/cygwin-ug-net.html. Much has changed, especially in terms of file handling. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
File name too long issues while using snv (subversion)
Is there a workaround? $ (pwd echo /hibernate-distribution-3.3.1.GA/project/testsuite/src/test/java/org/hibernate/t est/event/collection/association/bidirectional/on etomany/.svn/text-base/BidirectionalOneToManyBagSubclassCollectionEventTest.java .svn-base) | wc 2 2 262 -jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: File name too long issues while using snv (subversion)
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Jason Pyeron Sent: Tuesday, February 10, 2009 23:34 To: cygwin@cygwin.com Subject: File name too long issues while using snv (subversion) Is there a workaround? This is what I have found so far, but the process makes me feel unclean. http://www.okisoft.co.jp/esc/utf8-cygwin/ $ (pwd echo /hibernate-distribution-3.3.1.GA/project/testsuite/src/test/ja va/org/hibernate/t est/event/collection/association/bidirectional/on etomany/.svn/text-base/BidirectionalOneToManyBagSubclassCollec tionEventTest.java .svn-base) | wc 2 2 262 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: File name too long issues while using snv (subversion)
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Jason Pyeron Sent: Wednesday, February 11, 2009 0:30 To: cygwin@cygwin.com Subject: RE: File name too long issues while using snv (subversion) -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Jason Pyeron Sent: Tuesday, February 10, 2009 23:34 To: cygwin@cygwin.com Subject: File name too long issues while using snv (subversion) Is there a workaround? This is what I have found so far, but the process makes me feel unclean. http://www.okisoft.co.jp/esc/utf8-cygwin/ How can I make use of http://www.cygwin.com/ml/cygwin-developers/2008-03/msg0.html? $ (pwd echo /hibernate-distribution-3.3.1.GA/project/testsuite/src/test/ja va/org/hibernate/t est/event/collection/association/bidirectional/on etomany/.svn/text-base/BidirectionalOneToManyBagSubclassCollec tionEventTest.java .svn-base) | wc 2 2 262 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: File name too long issues while using snv (subversion)
On Wed, Feb 11, 2009 at 12:49:10AM -0500, Jason Pyeron wrote: How can I make use of http://www.cygwin.com/ml/cygwin-developers/2008-03/msg0.html? You obviously haven't been paying attention to Corinna's Cygwin 1.7 announcements. 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/
Solution or workaround for file name too long problem ?
Hello cygwin, is there any progress on the file name too long problem ? I think a lot of people would like to use rsync under cygwin for backup or replication, but as long as cygwin can't handle long path names this is not a serious option ... Is there at least a workaround you can recommend ? Best regards Klaus -- 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: Solution or workaround for file name too long problem ?
Klaus Tiedemann wrote: Hello cygwin, is there any progress on the file name too long problem ? I think a lot of people would like to use rsync under cygwin for backup or replication, but as long as cygwin can't handle long path names this is not a serious option ... Is there at least a workaround you can recommend ? Shorter paths. Best regards Klaus Try 1.7 snapshot if it fixes your problem. -- VH -- 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/
rsync Vista Client to Linux Server - readlink_stat - file name too long
Hi, I've installed cygwin and rsync/ssh on a vista client and want backup it to backuppc 3.1.0-2 on my Linux server: On client side (vista) I use rsync 3.0.4 (protocol version 30) Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, no IPv6, batchfiles, inplace, append, ACLs, no xattrs, iconv, symtimes On server side (linux) I have rsync 3.0.3 (protocol version 30) Capabilities: 64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints, socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, xattrs, iconv, symtimes In the logfile on Client side I found tons of messages like: 2008/10/27 21:36:02 [2327] rsync: readlink_stat(/Dokumente und Einstellungen/All Users/Application Data/Anwendungsdaten/Application Data/Anwendungsdaten/Anwendungsdaten/Application Data/Application Data/Application Data/Application Data/Application Data/Anwendungsdaten/Application Data/Start Menu/Programme (in C)) failed: File name too long (91) In the server logfile I see: full backup started for directory C (baseline backup #8) Connected to Loredana.mybackup:10025, remote version 30 Negotiated protocol version 28 Connected to module C Sending args: --server --sender --numeric-ids --perms --owner --group -D --links --hard-links --times --block-size=2048 --recursive --one-file-system --bwlimit=2840 --ignore-times . . Checksum seed is 1224438319 Got checksumSeed 0x48fb722f Sent exclude: /System Volume Information : What can I do? Is there a bug/feature with Vistas file links? Thanks in advance Matthias -- Don't Panic -- 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: File name too long problem -- maybe fix coming?
On Dec 18 21:06, Eric Blake wrote: According to Linda Walsh on 12/18/2007 3:30 PM: Is it possible the update quoted at the bottom will address or fix the path-len problem, mentioned below, in cygwin? Why not try out the snapshots, and see for yourself? But yes, it looks like Corinna is slowly getting to the point where cygwin uses native NT functions (which support absolute paths up to 32k in length), in such a way that you can access relative path names whose absolute name happens to be longer than PATH_MAX. And I'm sure that she will be adding openat() and friends along the way, which is what coreutils and findutils (and any other gnulib fts client) wants to use for optimal directory recursion. Maybe that goes without saying, after all this is an Open Source project, but I could really need some help here. The progress is extremly slow. There's just too much code to keep an eye upon. When I started I imagined we could release 1.7.0 in 2007 but as long as I have to do this conversion to unicode paths alone, it will take a lot more months. 2008? Well, maybe... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: File name too long problem -- maybe fix coming?
Is it possible the update quoted at the bottom will address or fix the path-len problem, mentioned below, in cygwin? Corinna Vinschen wrote: On Dec 1 15:43, Marty Leisner wrote: So for now I did a mount onto a shorter path and things worked fine: C:\Documents and Settings\leisner on /mnt type system (binmode) when I queried in /mnt... Whats the current status of this problem? Work in progress. Corinna --- Original Message Subject: Re: [PATCH]cp --recursive fails unnecessarily when the names of the latter approach become very long Date: Wed, 05 Dec 2007 09:31:07 +0100 From: Jim Meyering jim(at)meyering.net To: Cai Xianchao caixianchao(at)cn.fujitsu.com CC: bug-coreutils(at)gnu.org References: 47564085.4010907(at)cn.fujitsu.com Cai Xianchao caixianchao(at)cn.fujitsu.com wrote: The file TODO described a bug of cp (package:coreutils-6.9): cp --recursive: perform dir traversals in source and dest hierarchy rather than forming full file names. The latter (current) approach fails unnecessarily when the names become very long. We find that if the length of file name is not shorter than PATH_MAX, it will fail. Now, we have solved the problem by using the *at functions which were added to linux in kernel 2.6.16. If the kernel is older than 2.6.16, cp will run the same as before. Thank you very much for working on that problem! I wish you had announced your plan earlier -- I could have saved you some time. There are approximately 20 places in your patch where code like this has been added: fchdir (dst_relative_fd); ret_abandon_move = abandon_move (x, dst_relative_path, dst_sb); fchdir (currentpath_fd); True, that does achieve the goal of allowing longer names, but at the expense of changing the current directory. copy.c must not change the process's working directory, first because it is intended to be library-like, but also because ping-ponging back and forth via fchdir is unnecessary and hurts performance. Of course, on systems that lack native openat, copy still calls *at functions, but they go through gnulib's portability layer, which may call fchdir/chdir. But that's ok, because it affects only older and less-functional systems. Instead, you should use fts to perform the source-tree traversal. That handles most of the tricky details for you -- on the source side. However, in order to traverse the destination tree, you will have to maintain a single primary file descriptor, initially open on the parent of the destination directory -- or maybe on the destination directory itself. Then, as you create each new subdirectory (via mkdirat), you would advance that primary descriptor to a new one open on the just-created directory. Also, there is no need for #if directives like this: #if defined __USE_ATFILE defined PATH_MAX For examples of some of the things you will have to do with fts, see du.c, and ch*.c. Note also that with a file-descriptor-based traversal, it is no longer necessary to form full, relative file names while performing a traversal (except for diagnostics). And in fact, if you are not careful in how/when you form full names, you can mistakenly end up making the code inefficient (O(Depth^2)) for a deep hierarchy. For an example of how to do that, see the obstacks in remove.c's struct dirstack_state. If you pursue this, the FSF will need a copyright assignment from the author(s) of the work, and I see none on file yet. Have you already completed/mailed the necessary forms? If not, let me know and I'll send them. ___ Bug-coreutils mailing list Bug-coreutils(at)gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils -- 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: File name too long problem -- maybe fix coming?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Linda Walsh on 12/18/2007 3:30 PM: Is it possible the update quoted at the bottom will address or fix the path-len problem, mentioned below, in cygwin? Why not try out the snapshots, and see for yourself? But yes, it looks like Corinna is slowly getting to the point where cygwin uses native NT functions (which support absolute paths up to 32k in length), in such a way that you can access relative path names whose absolute name happens to be longer than PATH_MAX. And I'm sure that she will be adding openat() and friends along the way, which is what coreutils and findutils (and any other gnulib fts client) wants to use for optimal directory recursion. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHaJi584KuGfSFAYARAlP+AJwOjaaWkkyCBw3PDxqlz0XEeK7ltwCeJ1dD YAGNFGUtKVNDRUJwV1Z4FN8= =iXq9 -END PGP SIGNATURE- -- 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: File name too long problem
On Dec 1 15:43, Marty Leisner wrote: So for now I did a mount onto a shorter path and things worked fine: C:\Documents and Settings\leisner on /mnt type system (binmode) when I queried in /mnt... Whats the current status of this problem? Work in progress. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/
File name too long problem
I saw some postings on this from 2005.. http://cygwin.com/ml/cygwin/2005-04/msg00395.html When I did a du I got: du: cannot access `Temporary Internet Files/Content.IE5/WLCFOZCR/;_ylc=X1MDOTc1NDYxNjgEX3IDMgRmcmNvZGUDY3NjX3ltYWlsY2wEaXQDc2hvcnRjdXRzOi91cy9pbnN0YW5jZS9pZGVudGlmaWVyL1VSTARuX3R5cAMxBHNjbGFiZWwDaHR0cDovL290dGF3YS5raW[2].adNoOpfr=csc_ymailcl': File name too long du: cannot access `Temporary Internet Files/Content.IE5/WLCFOZCR/Type=clickFlightID=30975AdID=43842TargetID=8870Segments=1,9,3875,4301,4719,5878,6125,[1].11%2CZIPCODE%2C14601%2CAREACODE%2C585%2CUSERID%2CRedirect=;ord=bfmsebi,bdqKxryhjorl': File name too long So for now I did a mount onto a shorter path and things worked fine: C:\Documents and Settings\leisner on /mnt type system (binmode) when I queried in /mnt... Whats the current status of this problem? marty -- 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/
Rsync 2.6.9: File name too long (91)
Hi, We are having the same problem then the one you already answers last year in: http://www.cygwin.com/ml/cygwin/2005-04/msg00395.html Since the cygwin-1.5.21-1 specified that future release might not support win_9x Do you have any plan for supporting longer path/filename than the actual 260 byte limit? -- JPL -- 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: Rsync 2.6.9: File name too long (91)
JPL wrote: Hi, We are having the same problem then the one you already answers last year in: http://www.cygwin.com/ml/cygwin/2005-04/msg00395.html Since the cygwin-1.5.21-1 specified that future release might not support win_9x Do you have any plan for supporting longer path/filename than the actual 260 byte limit? I think Corrina outlined the basics of what needs to be done quite well. This would be one place which would cause an incompatibility with non-NT- based platforms of course. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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/
cygpath error: file name too long
Hi, I have two machines which, as far as I know, have the same setup. Using the same PATH string, one fails when trying to convert it with cygpath and one doesn't. The error is saying that the file name is too long. Can anyone suggest some windows or cygwin setting that might be slightly different on both machines that would cause this error? Thanks a lot. Chris -- 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: cygpath error: file name too long
On 10 May 2006 18:22, Capaci, Christopher wrote: Hi, I have two machines which, as far as I know, have the same setup. Using the same PATH string, one fails when trying to convert it with cygpath and one doesn't. The error is saying that the file name is too long. Can anyone suggest some windows or cygwin setting that might be slightly different on both machines that would cause this error? Thanks a lot. You have different mountpoints on both machines, which means that some of the converted path entries have longer prefixes on one of them and so the whole thing becomes too long? Perhaps you'd better do the cygcheck thing on both machines and diff them. cheers, DaveK -- Can't think of a witty .sigline today -- 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: Unexpected File Name Too Long Error With #includes
All, To recap my original post of 08/17/2005 on this issue, I had a situation where I was trying to #include a fairly long path in a C program. If the full path was given in-line, then the #include succeeded. If part of the path was given in the source, and the prefix was given as a -I option, then the #include failed. I finally figured out what was going on with this and thought I'd share in case it's of interest to anyone (this perhaps is more appropriate for the gcc list(s), but given that Windows is a bit tighter on path lengths - and therefore more likely to produce this problem - it also seemed relevant to the cygwin list). The problem was that the #include was using quotes rather than carets, and cc1 of course made an attempt to resolve the #include relative to the current working directory. In my case the current working directory itself was buried down a deep directory structure such that the working directory's path with the #include path tacked onto the end resulted in a path that exceeded the limit. The simplest example of this problem could be demonstrated by running cc1 directly. cppfiles.c in gcc is where the relevant stuff happens. Ultimately the open_file function is called, which calls open, then some magic happens, and somewhere at the end normalize_posix_path is called from path.cc. normalize_posix_path is where the ENAMETOOLONG errno was coming from. The non-zero errno makes its way back to the stuff in cppfiles.c and ultimately causes the preprocessor to give up. I argued with myself over whether it was reasonable for the preprocessor to bail on this condition. A file #included with quotes will either be found or not. I finally won the argument :-) and concluded that it may not be found because it either doesn't exist or because the path is too long (in which case it can't exist), but either way it doesn't exist and the -I paths should be tried. I don't know what cc1 does on other platforms e.g. Linux if this condition happens. It probably would do the same thing and we just don't see it because the path restrictions are more liberal. FWIW, Rob Rob Hatcherson wrote: Dave Korn wrote: Original Message From: Rob Hatcherson Sent: 17 August 2005 20:49 All, This issue involves a File name too long error being generated by the C preprocessor that came along with 1.5.18-1. The compiler reports version 3.4.4, the distro file says 3.4.4-1. I can #include this header file directly in a .c file with no problem: #include C:/d1/d2/d3/d4/...lots more.../blah.h The problem occurs if I provide a part of this path via a -I option, and put the remainder inside quotes in the #include. So say I do this: gcc -E -I C:/d1/d2/d3/d4 blah.c ...with the source file looking notionally like this: #include ...lots more.../blah.h What I'm wondering is if it's not the concatenation of C:/d1/d2/d3/d4 with ...lots more.../blah.h that is too long, but the concatenation of one of the _other_ -I search prefix dirs with ...lots more.../blah.h that overflows, and then (and this would indeed be a bug in cpp) the preprocessor gives up after getting an error code, rather than continuing the attempt with the remaining entries on the search path list. You could test this theory by attempting the compile that fails again with the -v -E options, just to get the exact command line that is used to invoke cc1.exe; then rewrite it and try messing with the the -I options so that your C:/d1/d2/d3/d4 prefix comes first in the search list, or chop out all the -I options except your own one and add -nostdinc This was a great theory, and when I initially read this I thought you probably had it nailed. But alas, this doesn't seem to be the problem. Of all the -I options provided, the longest path (which happens to be the one against which the problematic #include should be resolved) when cat'd with the #include'd part is still well within the Windows path length limit, and I can still #include the entire path verbatim with no problem. Unfortunately I had a deadline to meet yesterday and had to resort to chopping out some path components to get the length down, and also haven't had time to examine the preprocessor source to see what's going on. If/when I learn anything I'll chime in again. Thanks for the feedback... Rob -- 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/ -- 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: Unexpected File Name Too Long Error With #includes
Original Message From: Rob Hatcherson Sent: 17 August 2005 20:49 All, This issue involves a File name too long error being generated by the C preprocessor that came along with 1.5.18-1. The compiler reports version 3.4.4, the distro file says 3.4.4-1. I can #include this header file directly in a .c file with no problem: #include C:/d1/d2/d3/d4/...lots more.../blah.h The problem occurs if I provide a part of this path via a -I option, and put the remainder inside quotes in the #include. So say I do this: gcc -E -I C:/d1/d2/d3/d4 blah.c ...with the source file looking notionally like this: #include ...lots more.../blah.h What I'm wondering is if it's not the concatenation of C:/d1/d2/d3/d4 with ...lots more.../blah.h that is too long, but the concatenation of one of the _other_ -I search prefix dirs with ...lots more.../blah.h that overflows, and then (and this would indeed be a bug in cpp) the preprocessor gives up after getting an error code, rather than continuing the attempt with the remaining entries on the search path list. You could test this theory by attempting the compile that fails again with the -v -E options, just to get the exact command line that is used to invoke cc1.exe; then rewrite it and try messing with the the -I options so that your C:/d1/d2/d3/d4 prefix comes first in the search list, or chop out all the -I options except your own one and add -nostdinc cheers, DaveK -- Can't think of a witty .sigline today -- 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: Unexpected File Name Too Long Error With #includes
Dave Korn wrote: Original Message From: Rob Hatcherson Sent: 17 August 2005 20:49 All, This issue involves a File name too long error being generated by the C preprocessor that came along with 1.5.18-1. The compiler reports version 3.4.4, the distro file says 3.4.4-1. I can #include this header file directly in a .c file with no problem: #include C:/d1/d2/d3/d4/...lots more.../blah.h The problem occurs if I provide a part of this path via a -I option, and put the remainder inside quotes in the #include. So say I do this: gcc -E -I C:/d1/d2/d3/d4 blah.c ...with the source file looking notionally like this: #include ...lots more.../blah.h What I'm wondering is if it's not the concatenation of C:/d1/d2/d3/d4 with ...lots more.../blah.h that is too long, but the concatenation of one of the _other_ -I search prefix dirs with ...lots more.../blah.h that overflows, and then (and this would indeed be a bug in cpp) the preprocessor gives up after getting an error code, rather than continuing the attempt with the remaining entries on the search path list. You could test this theory by attempting the compile that fails again with the -v -E options, just to get the exact command line that is used to invoke cc1.exe; then rewrite it and try messing with the the -I options so that your C:/d1/d2/d3/d4 prefix comes first in the search list, or chop out all the -I options except your own one and add -nostdinc This was a great theory, and when I initially read this I thought you probably had it nailed. But alas, this doesn't seem to be the problem. Of all the -I options provided, the longest path (which happens to be the one against which the problematic #include should be resolved) when cat'd with the #include'd part is still well within the Windows path length limit, and I can still #include the entire path verbatim with no problem. Unfortunately I had a deadline to meet yesterday and had to resort to chopping out some path components to get the length down, and also haven't had time to examine the preprocessor source to see what's going on. If/when I learn anything I'll chime in again. Thanks for the feedback... Rob -- 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/
Unexpected File Name Too Long Error With #includes
All, This issue involves a File name too long error being generated by the C preprocessor that came along with 1.5.18-1. The compiler reports version 3.4.4, the distro file says 3.4.4-1. I have a header file whose total path length is 190 characters counting drive letters (yeah, I know it's ridiculously long, and I can get around this problem by chopping some stuff out, but at the moment I'm wondering what I'm missing for future reference). I can #include this header file directly in a .c file with no problem: #include C:/d1/d2/d3/d4/...lots more.../blah.h The problem occurs if I provide a part of this path via a -I option, and put the remainder inside quotes in the #include. So say I do this: gcc -E -I C:/d1/d2/d3/d4 blah.c ...with the source file looking notionally like this: #include ...lots more.../blah.h By experimentation (with this particular file I'm having problems with, so this isn't a general observation) when the total length of the stuff inside the quotes in the #include statement reaches 82 characters in length I get a File name too long error from the preprocessor. Yet as noted earlier I can include the entire path inline without a complaint. I've been using Cygwin for a while now and can't recall ever having a path length problem unless the length exceeded the total path limit at the Windows level (250, or 253, or 255, or whatever it is). So... this makes me wonder if perhaps some feature has been introduced that I'm missing, and/or there's some magic option I need to be using. Has anybody else encountered this behavior? Sorry if this is a well-known issue. I've been poking around a bit and haven't seen anything relevant (yet). I'm currently digging in the gcc-core source, but thought I'd ping the group in the meantime. TIA, Rob Hatcherson ZedaSoft, Inc. -- 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: File name too long (91)
On Apr 10 02:07, Xu?n Baldauf wrote: Hello, I'm hitting File name too long (91) errors when using rsync or even ls within cygwin. I tracked down this problem to the constant CYG_MAX_PATH, which seems to be defined in cygtls.h. Would it be a problem to rise this limit? Yes. The main reason is, it won't work. Cygwin is using the ASCII variations of Win32 functions which limit the path length to 260 characters, including the trailing 0. Just raising a define won't change anything. The real long term solution is to use the WideChar variations of the Win32 functions or the NT API instead, but that would not work on 9x (heh, *I*'m sayin that) and even then, it's a lot of work, especially to do it right. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/
File name too long (91)
Hello, I'm hitting File name too long (91) errors when using rsync or even ls within cygwin. I tracked down this problem to the constant CYG_MAX_PATH, which seems to be defined in cygtls.h. Would it be a problem to rise this limit? So, is there any objection to a patch like this? --- winsup/cygwin/cygtls.h.orig 2005-03-31 17:46:24.0 +0200 +++ winsup/cygwin/cygtls.h 2005-04-10 02:01:42.0 +0200 @@ -23,7 +23,7 @@ #define CYGTLS_EXCEPTION (0x43227 + true) #ifndef CYG_MAX_PATH -# define CYG_MAX_PATH 260 +# define CYG_MAX_PATH 520 #endif #ifndef UNLEN I have directory trees which certainly exceed the old limit... ciao, Xuân. -- 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/
