This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Fonts reorganization and additions
- From: Ken Brown <kbrown at cornell dot edu>
- To: cygwin at cygwin dot com
- Date: Sun, 13 Sep 2015 12:10:48 -0400
- Subject: Re: Fonts reorganization and additions
- Authentication-results: sourceware.org; auth=none
- References: <1441962346 dot 9784 dot 34 dot camel at cygwin dot com> <55F2B932 dot 8060101 at gmail dot com> <55F30150 dot 8020906 at cornell dot edu> <1441989600 dot 15240 dot 4 dot camel at cygwin dot com> <55F327B4 dot 40208 at cornell dot edu> <1442001550 dot 9548 dot 6 dot camel at cygwin dot com>
On 9/11/2015 3:59 PM, Yaakov Selkowitz wrote:
The first thing that should be checked is if the code in setup which
allows it to unpack files with "illegal" characters in Windows also
makes sure to create parent directories. Based on these reports my
*guess* is it doesn't but I haven't looked yet.
I'm not very familiar with the setup code, but I think I may have found the
problem. The function mkdir_p() in mkdir.cc contains the following, starting at
line 99:
for (c = path; *c; c++)
{
if (*c == ':')
slash = 0;
if (*c == '/' || *c == '\\')
slash = c;
}
if (!slash)
return 0;
If I understand this correctly, the function will return success without having
created the leading directory if the path name contains a colon and doesn't
contain a slash after the last colon. I guess the assumption is that there is
no "leading directory" to be created in this case. [This part of the code was
written in 2000, when a colon could not be part of a file name.]
I hope someone who understands the setup code better than I do can take a look
at this. I'm not confident that I understand all the uses of mkdir_p() or all
possible reasons why its in_path argument might contain a colon.
Ken
--
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