lstat() fails intermittently in C program -- what could cause this???
Greetings, I am having problems with intermittent failures of the lstat() inside a C program on several servers running Windows Server 2008R2. The program recursively searches directories and uses lstat() to gather information on each file. The files that fail most often end in .bak, but not always. Since the lstat() command does not return detailed failure information, I can't identify what is causing the failure. Any suggestions on what might be causing the failures or how to gather information on what is causing the failure? Help is GREATLY appreciated. Leon -- 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: Possible Bug (clarification) in Cygwin 1.7.5 -- findfirstfile (and findnextfile) yeild bad cfilename when file names have special characters. Works in cygwin 1.5, fails in 1.7
Many thanks to Charles and Corinna for the help. I have modified the code to use the POSIX functions. I still have one problem I cannot seem to conquer. I need to be able to read and write the (yes, I know it's evil) archive bit. Unless there is a POSIX function (which I seriously doubt) for these items, I am locked into the windows APIs. I have read and re-read the Cygwin documentation on internationalization at least 6 times and I cannot figure out what I need to do to get this to work. I have tried numerous combinations of environment variables and locale settings in the code, but none of them work. The windows API fails to find the file specified. I just want US English that can handle the extended character set to the windows APIs. In this case, let's use the example of the copyright symbol (the small c with a circle around it). What needs to be set in the environment, and what needs to be set in the C code to handle these characters correctly? Your help and assistance is GREATLY appreciated. Leon Leon Vanderploeg Cell 303-877-9654 On Nov 3 17:56, Charles Wilson wrote: On 11/3/2011 4:48 PM, Leon Vanderploeg wrote: With cygwin 1.7.5, cFileName with a special characters such as ñ (n with tidle above it) fail be properly extracted from a WIN32_FIND_DATA structure with findFirstFile (or findNextFile). To set up a simple test scenario, I created a file in C:\Testing named Mañana.docx. I compiled the code at the end of this message on Cygwin 1.7.9 with GCC version 3.4.4 on Server 2008 32 bit system. On this system (and on a Windows 7 32 bit machine), it returns: a) Why are you using native Win32 APIs in a cygwin program? You should be using the POSIX interfaces instead -- see /usr/include/dirent.h. DIR *opendir (const char *); DIR *fdopendir (int); struct dirent *readdir (DIR *); int readdir_r (DIR *, struct dirent *, struct dirent **); void rewinddir (DIR *); int closedir (DIR *); ACK++ b) What you observe is an artifact of cygwin-1.7's new *support* for i18n. In cygwin-1.5, it just didn't care and passed all the bytes back exactly as found without transliteration. In 1.7, it (correctly) transcodes strings into the current locale -- and your current locale does not appear to support ñ -- or, at least, you haven't told cygwin to use the correct one. (I'm probably thoroughly botching this explanation, but the point is, Just a bit. What you have to keep in mind is that Windows stores all object names, including filenames, as UTF-16 strings, UNICODE in Windows terminology. When you use the ANSI Win32 API as in this example, then the UTF-16 names are converted to the currently defined ANSI charset on output, for instance codepage 1252 for Western Europe languages. Cygwin 1.5 either used the ANSI API, or it converted strings from UTF-16 to the current Windows ANSI charset or vice versa. Cygwin 1.7 doesn't use the ANSI API anymore, rather it uses UNICODE to talk to Windows only, and the multibyte charset is defined through the environment(*) as defined in POSIX. UTF-8 is the default now. you need to check your LC_* and LANG env vars, and maybe call setlocale(LC_ALL, ) in your application.) And even than the code won't work. If you don't define UNICODE, FindFirstFile/FindNextFile will use the ANSI versions of this API, FindFirstFileA/FindNextFileA. If you didn't set your LANG/LC_CTYPE/LC_ALL variables to use your current Windows ANSI charset *and* called setlocale, Cygwin will use UTF-8 by default. Therefore, the character ñ will have another multibyte encoding, 0xc3 0xb1, rather than, say, 0xf1 in Windows codepage 1252. To avoid this problem, you can use the UNICODE API FindFirstFileW/ FindNextFileW and convert the filename the current multibyte charset via wcstombs and friends. However, as Chuck has pointed out, the obviously right thing to do is to use the POSIX API opendir/readdir/closedir instead. Corinna -- 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
Possible Bug (clarification) in Cygwin 1.7.5 -- findfirstfile (and findnextfile) yeild bad cfilename when file names have special characters. Works in cygwin 1.5, fails in 1.7
Greetings,
This issue is making my head flat from pounding it against the wall. It
appears to be a bug in Cygwin 1.7, but I can't say with any certainty. I've
been down too many dead end trails already...
With cygwin 1.7.5, cFileName with a special characters such as ñ (n with tidle
above it) fail be properly extracted from a WIN32_FIND_DATA structure with
findFirstFile (or findNextFile).
To set up a simple test scenario, I created a file in C:\Testing named
Mañana.docx. I compiled the code at the end of this message on Cygwin 1.7.9
with GCC version 3.4.4 on Server 2008 32 bit system. On this system (and on a
Windows 7 32 bit machine), it returns:
$ ./winfilestat3.exe
hFind filename is ***Ma▒ana.docx***
hFind file name stat return code is: -1
character 0 is M
character 0 is signed int 77, hex 4d
character 1 is a
character 1 is signed int 97, hex 61
character 2 is ▒
character 2 is signed int -15, hex fff1
character 3 is a
character 3 is signed int 97, hex 61
character 4 is n
character 4 is signed int 110, hex 6e
character 5 is a
character 5 is signed int 97, hex 61
character 6 is .
character 6 is signed int 46, hex 2e
character 7 is d
character 7 is signed int 100, hex 64
character 8 is o
character 8 is signed int 111, hex 6f
character 9 is c
character 9 is signed int 99, hex 63
NOTE that the ñ is interpreted as ▒, and the stat fails.
I moved the compiled program to an old Server 2003 running Cygwin 1.5.25. It
CORRECTLY returns:
bash-3.2$ ./winfilestat3.exe
hFind filename is ***Mañana.docx***
hFind file name stat return code is: 0
character 0 is M
character 0 is signed int 77, hex 4d
character 1 is a
character 1 is signed int 97, hex 61
character 2 is ñ
character 2 is signed int -15, hex fff1
character 3 is a
character 3 is signed int 97, hex 61
character 4 is n
character 4 is signed int 110, hex 6e
character 5 is a
character 5 is signed int 97, hex 61
character 6 is .
character 6 is signed int 46, hex 2e
bash-3.2$
bash-3.2$
Note the ñ is correct, and the stat succeeds.
Is this a bug, or do I need to set something up special on Cygwin 1.7 to get it
to work the way it used to?
Thanks in advance,
Leon
**start of code #include string.h #include
unistd.h #include stdio.h #include sys/stat.h #include stdlib.h
#include string.h
#include unistd.h
#include stdio.h
#include sys/stat.h
#include stdlib.h
#include time.h
#include windows.h
#include winbase.h
#include sys/types.h
#include fcntl.h
#include dirent.h
#include curl/curl.h
#include pthread.h
#include wctype.h
#include sys/wait.h
#include cygwin/wait.h
struct stat fileStat;
WIN32_FIND_DATA FindFileData;
HANDLE hFind;
int main(int argc, char **argv)
{
char filename[100];
int rtn, i;
char chr;
//find file
char pathSearch[300];
sprintf(pathSearch, C:\\Testing\\*.docx);
hFind = FindFirstFile(pathSearch, FindFileData);
if (hFind == INVALID_HANDLE_VALUE)
{
printf(Warning: No .docx file found in the directory.
Exiting.\n);
return(1);
}
strcpy(filename, FindFileData.cFileName);
printf(hFind filename is ***%s***\n,filename);
rtn = stat(filename,fileStat);
printf(hFind file name stat return code is: %d\n, rtn);
for ( i = 0 ; i wcslen(filename) ; i++ )
{
printf(character %d is %c\n, i, filename[i] );
printf(character %d is signed int %d, hex %x \n, i,
filename[i], filename[i] );
}
return(0);
}
**end of code
Leon Vanderploeg
Cell 303-877-9654
--
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
Possible Bug ???
= FindFirstFile(pathSearch, FindFileData);
if (hFind == INVALID_HANDLE_VALUE)
{
printf(Warning: No .docx file found in the
directory. Exiting.\n);
return(1);
}
strcpy(filename, FindFileData.cFileName);
printf(hFind filename is ***%s***\n,filename);
rtn = stat(filename,fileStat);
printf(hFind file name stat return code is: %d\n, rtn);
for ( i = 0 ; i wcslen(filename) ; i++ )
{
printf(character %d is %c\n, i, filename[i] );
printf(character %d is signed int %d, hex %x
\n, i, filename[i], filename[i] );
}
return(0);
}
**end of code
Leon Vanderploeg
Cell 303-877-9654
--
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
possible bug in stat() -- not working with special characters on 64 bit systems
I have been fighting a problem with a compiled C program and seem to have
narrowed it down. When file names contain special characters such as the n
with the tilde above it (ñ), stat() works fine on 32 bit machines, but fails
on 64 bit machines (both windows 7 and server 2008 R2).
At the end of the this email is source code of a small test program to
demonstrate the issue. Of course, the C:\ directory must contain the
Mañana.doc and Manana.doc files. I can provide a compiled version if
needed. The program is compiled on Cygwin version 1.5.25, GCC version
3.4.4.
On 32 bit machines, stat() succeeds for both files, on 64 bit machines, the
stat() of Manana.doc succeeds but Mañana.doc fails.
Can someone please test and confirm if this is, indeed, a bug?
Thanks,
Leon V
*start of source code
#include string.h
#include unistd.h
#include stdio.h
#include sys/stat.h
#include stdlib.h
#include time.h
#include windows.h
#include winbase.h
#include sys/types.h
#include fcntl.h
#include dirent.h
#include curl/curl.h
#include pthread.h
#include sys/wait.h
#include cygwin/wait.h
int main(int argc, char **argv)
{
char filename[100];
int rtn;
strcpy(filename, C:\\Mañana.doc);
printf(filename is ***%s***\n,filename);
struct stat fileStat;
rtn = stat(filename,fileStat);
printf(stat return code is: %d\n, rtn);
strcpy(filename, C:\\Manana.doc);
printf(filename is ***%s***\n,filename);
rtn = stat(filename,fileStat);
printf(stat return code is: %d\n, rtn);
return(0);
}
*end of source code*
--
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
How To Handle Special Characters in Cygwin, E.G., Trademark Symbol, n with the tilde above it
Greetings, I have recently encountered a problem with accessing files that have special characters in the file names. The special characters include (a couple examples) the trademark symbol and the n with a tilde above it. The recommendation from http://www.cygwin.com/cygwin-ug-net/using-specialnames.html; is: = Filenames with unusual (foreign) characters Windows filesystems use Unicode encoded as UTF-16 to store filename information. If you don't use the UTF-8 character set (see the section called Internationalization) then there's a chance that a filename is using one or more characters which have no representation in the character set you're using. Note In the default C locale, Cygwin creates filenames using the UTF-8 charset. This will always result in some valid filename by default, but again might impose problems when switching to a non-C or non-UTF-8 charset. Note To avoid this scenario altogether, always use UTF-8 as the character set. = Suggestions on how to access these files? Thanks in advance... Leon -- 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
Compiled Program System Calls Failing Code 127
Greetings, I have a compiled C program that is installed on several servers. It makes system calls to programs such as rsync, and has worked fine until now. I recently installed it on two Server 2008R2 boxes, identical hardware. Both are Cygwin 1.7.9. C:\cygwin\bin is added to the Windows PATH variable on both machines. The program runs fine on one box, but on the other box, the system calls return 127. http://cygwin.com/ml/cygwin/2006-08/msg00347.html says /bin/sh cant be found. At the escalated command prompt, bash and sh start appropriate shells (although the which command points to /usr/bin/xxx) on both machines. Any idea what could be causing this behavior? Thanks in advance for any assistance. Leon -- 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
Cygwin 1.7.8 on Windows 7 Pro x64 Doesn't See Programs Added to C:\Windows\System32 Directory
Greetings, I recently loaded Windows 7 Pro x64 on my laptop, and installed Cygwin 1.7.8. I run a (GCC Compiled) backup program that calls diskshadow.exe -- which I added to the C:\Windows\System32 directory. The program faults because the shell call can't find the program. The Path variable is set with C:\Windows\System32 as the first entry, and there are no errors. I've started new command prompts each time I edited the Windows PATH variable, and even tried rebooting. Opening an elevated command prompt, windows finds the program just fine from the path variable. Running Bash, the which command doesn't find diskshadow.exe, even though it is there (in C:\Windows\System32). While still in the bash window (from an elevated command prompt), If I cd to /cygdrive/c/Windows/System32 and do ls -la disk*, it finds other disk programs such as diskpart.exe, but not diskshadow.exe, even though I know it is there! This is also true of libcurl-3.dll that I added to C:\Windows\System32.Windows sees it fine, but not bash. I have been reading documentation and googling till I can't see straight. Can anyone please help me understand what is happening? Thanks in advance! Leon -- 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: Cygwin Support for Shadow Copies Exposed As Drives?
References: 002b01cbac64$54079040$fc16b0c0$@vaultnow.com Bump Leon Vanderploeg Business Data Protection, LLC Cell: 303-877-9654 -- 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: Cygwin Support for Shadow Copies Exposed As Drives?
I didn't see an email reply to 008801cbab56$59188f30$0b49ad...@vaultnow.com in my email, but I did see a reply in the forum. I am not sure about the right way to get back to the original item, but I'm hoping this will get it there. Re: Cygwin Support for Shadow Copies Exposed As Drives? From: Larry Hall \(Cygwin\) reply-to-list-only-lh at cygwin dot com To: cygwin at cygwin dot com Date: Mon, 03 Jan 2011 18:17:59 -0500 Subject: Re: Cygwin Support for Shadow Copies Exposed As Drives? References: 008801cbab56$59188f30$0b49ad...@vaultnow.com Reply-to: cygwin at cygwin dot com On 1/3/2011 9:56 AM, Leon Vanderploeg wrote: I have hit a brick wall in the Cygwin 1.7 arena -- shadow copies exposed as drives can no longer be accessed. See http://cygwin.com/ml/cygwin/2009-07/msg00954.html for an example of previous documentation on this issue. Are there any plans for a patch or work-around to allow an exposed shadow drive to be accessed by a program such as rsync? Thanks in advance, and best regards, Leon Have you tried a recent snapshot? http://cygwin.com/snapshots/ -- Larry Hi Larry, Thanks for the quick reply. I just pulled down the 2010-12-29. It, to failed the rsync chdir to an exposed drive. I scanned the change logs on all the snapshots listed on the page you suggested and I didn't see anything on shadow copies. Best regards, Leon Leon Vanderploeg Business Data Protection, LLC Cell: 303-877-9654 -- 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
Cygwin Support for Shadow Copies Exposed As Drives?
I have hit a brick wall in the Cygwin 1.7 arena -- shadow copies exposed as drives can no longer be accessed. See http://cygwin.com/ml/cygwin/2009-07/msg00954.html for an example of previous documentation on this issue. Are there any plans for a patch or work-around to allow an exposed shadow drive to be accessed by a program such as rsync? Thanks in advance, and best regards, Leon Leon Vanderploeg Business Data Protection, LLC Cell: 303-877-9654 -- 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
