Re: thunking, the next step
On Fri, Nov 14, 2003 at 02:10:10PM -0500, Christopher Faylor wrote: On Sat, Nov 15, 2003 at 04:52:43AM +1100, Robert Collins wrote: On Sat, 2003-11-15 at 02:57, Christopher Faylor wrote: On Fri, Nov 14, 2003 at 11:02:11PM +1100, Robert Collins wrote: Ok, I've now integrated and generalised Ron's unicode support mini-patch. So, here tis a version that, well the changelog explains the overview, and io.h the detail. Overhead wise, this is reasonably low: 1 strlen() per IO call minimum. 1 unicode conversion, only if needed. And a couple of tests for do we do unicode for every call. Which are all inline aren't they? I guess I don't see the overhead as significant compared to the strlen generation. I'd rather just make the decision at initialization time if we can. Possibly we could extend the function loader to either call FooW or FooA as appropriate when Foo is specified. Given that we know on which system we run, we can use the wincap information to load the correct function through the autoloader functionality. This would require a decision only on the first time a function is called. There's just a problem with the header files. Let's say, all the other Cygwin code uses the non-explicit name (e. g. CreateFile, not CreateFileA or CreateFileW). The decision which function actually to use is done in the autoload part. The problem is this: The Win32 header files decide by themselves, which of the functions to use: #ifdef UNICODE #define CreateFile CreateFileW #else #define CreateFile CreateFileA #endif To workaround this, we must care for undefining all affected function names before using them, probably best in an autoload.h header or so. Also we would need a fairly big change to path_conv. It would have to create the POSIX path in ascii on 9x and in wide char on NT. If the path name creation is done in wide char directly, we neither need a strlen, nor an explicit conversion from ascii to wide char. I think this method is preferable over the IOThunkState technique since it will have more or less no speed impact. It also has the advantage, that the Cygwin code doesn't have to use all new function calls like create_file instead of using the real Win32 function calls directly. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
Re: thunking, the next step
On Mon, Nov 17, 2003 at 10:31:29PM +1100, Robert Collins wrote: On Mon, 2003-11-17 at 22:21, Corinna Vinschen wrote: This would require a decision only on the first time a function is called. There's more to it than that. you MUST NOT hand the A series call longer paths than MAX_PATH, they /really/ don't like it. That's easily straightened out in path_conv. And, structures like the FindNext* details change in definition when UNICODE is defined. I was trying to avoid all that complexity, which is significant, by staying in a thunk approach. Yep, I agree, that's an extra problem. But it doesn't invalidate the general idea of putting the work into autoload and path_conv. The FindFile example might be something which justifies the use of wrapper functions for these very cases. I decided against redefining the 'real' calls because I figured some areas may want to use the 'real' calls directly, and only the auto-adjusting parts of cygwin should have the ansi/wide dichotomy. I don't know if I understand you right. I was only talking about calls which are affecting the file system. Other calls like CreateSemaphore or what not should still work as before. The autoload part would define some new LoadDLLfuncBLURB which is used only for the affected functions. I (and I assume cgf) was not talking about using that approach for all functions with an ascii and a wide char implementation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc.
RE: The increased path length changes
-Original Message- From: Christopher Faylor [mailto:[EMAIL PROTECTED] 1) Does Ron Parker have an assignment on file with Red Hat? I can't find one, if so. This will be a requirement if the patches are accepted. The mechanical change that was just checked in is ok but any more substantial changes will need an assignment. My assignment may date back to Geoff Naur. I will gladly resubmit one. I will try to print it out Tonight and send it to Rose Naftaly, as per assign.txt.
RE: thunk createDirectory and createFile calls
-Original Message- From: Robert Collins [mailto:[EMAIL PROTECTED] On Sat, 2003-11-15 at 02:52, Christopher Faylor wrote: It is a given that we're working in cygwin. Adding a cygwin_ to the beginning of a function is just noise. Heh, will fix... was following Ron's convention semi-blindly. Who was following Rob's suggestion for a cygwin_CreateFile semi-blindly. :^)
(fhandler_base::lseek): Include high order bits in return.
This bug fix got our app past its first problem with 2 Gig files, but
then it tripped over ftello. I'm still trying to figure that one out.
It looks like it got a 32 bit sign extended value somewhere. Any help would
be appreciated. Thanks.
2003-11-17 Brian Ford [EMAIL PROTECTED]
* fhandler.cc (fhandler_base::lseek): Include high order offset
bits in return value.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444Index: fhandler.cc
===
RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
retrieving revision 1.161
diff -u -p -r1.161 fhandler.cc
--- fhandler.cc 25 Oct 2003 12:32:56 - 1.161
+++ fhandler.cc 17 Nov 2003 20:54:34 -
@@ -874,6 +874,9 @@ fhandler_base::lseek (_off64_t offset, i
}
else
{
+ if (poff_high)
+ res += (_off64_t) *poff_high 32;
+
/* When next we write(), we will check to see if *this* seek went beyond
the end of the file, and back-seek and fill with zeros if so - DJ */
set_did_lseek ();
RE: Additional Cygwin long file path patch
From: Parker, Ron [mailto:[EMAIL PROTECTED] From: Robert Collins [mailto:[EMAIL PROTECTED] 1a) Update CYG_MAX_PATH to (say) 270. Check for issues with the change occuring, and rectify. I actually bumped CYG_MAX_PATH to 520, double its previous value. It seems to be work for me and allows tla to actually create deep paths. rbc02-cyg-max-path-520.diff Description: Binary data
Re: (fhandler_base::lseek): Include high order bits in return.
On Mon, 17 Nov 2003, Brian Ford wrote:
On Mon, 17 Nov 2003, Corinna Vinschen wrote:
On Mon, Nov 17, 2003 at 03:40:46PM -0600, Brian Ford wrote:
On Mon, 17 Nov 2003, Brian Ford wrote:
This bug fix got our app past its first problem with 2 Gig files, but
then it tripped over ftello. I'm still trying to figure that one out.
It looks like it got a 32 bit sign extended value somewhere. Any help would
be appreciated. Thanks.
Well, that somewhere is ftello64.c line 111. fp-_offset has a 32 bit
sign extended value. Anybody know how it got there?
That can't be it. fp is of type FILE which is actually mapped to
__sFILE64 in 64 bit case. See newlib/libc/include/sys/reent.h.
_offset is of type _off64_t there.
I think you misunderstood. fp-_offset is a 64 bit type, but at the
ftello call in question, it contains a value that must have come from a 32
bit sign extension. That's why I asked for help, because I have to figure
out what/who put it there.
I have attached a test case that shows the problem. It is on line 58 of
lseekr.c.
I can't seem to find the actual problem tonight and I'm tired so I'm going
home.
--
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax: 314-551-8444#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdlib.h
#include stdio.h
#include unistd.h
int
main(void)
{
FILE *fp;
off_t p, q;
char c;
long long size = 50LL;
int fd = open(junk, O_RDWR|O_CREAT, S_IREAD|S_IWRITE);
lseek(fd, size, SEEK_SET);
write(fd, x, 1);
close(fd);
fp = fopen(junk, r);
p = fseeko(fp, size, SEEK_SET);
fprintf(stderr, %c , fgetc(fp));
q = ftello(fp);
fprintf(stderr,%llx %llx %llx\n,size,p, q);
}
Re: Small patch for the FAQ
At 10:37 PM 11/13/2003 +, David Starks-Browning wrote:
It will be *quite* some time before I am able to wade through the
main
cygwin list and discover things for the FAQ on my own. But I
should
be able to apply patches on a fairly regular and timely basis,
at
least for a while.
Thanks David.
I attach a patch to install.texinfo that covers
http://www.cygwin.com/ml/cygwin/2003-03/msg00447.html and
http://cygwin.com/ml/cygwin-patches/2003-q1/msg00315.html
but not (among others)
http://www.cygwin.com/ml/cygwin/2003-04/msg01416.html
Pierre
Index: install.texinfo
===
RCS file: /cvs/src/src/winsup/doc/install.texinfo,v
retrieving revision 1.45
diff -u -p -r1.45 install.texinfo
--- install.texinfo 10 Apr 2003 20:09:35 - 1.45
+++ install.texinfo 18 Nov 2003 03:35:33 -
@@ -40,6 +40,31 @@ from the rest of your Windows system dis
(In the past, there had been genuine bugs that would cause problems
for people who installed in C:\, but we believe those are gone now.)
[EMAIL PROTECTED] How are file permissions determined
+
+The directories and files created by setup inherit the default ACL of their
+parent directory. Thus in a fresh installation all permissions are initially
+determined by the ACL of the top directory (e.g. @samp{C:\} for an
+installation in @samp{C:\cygwin}).
+
+After running setup it is a good idea to verify the permissions with the
+Windows program ``cacls'', which shows the true ACL,
+or with ``ls -l /bin'', which shows the mapping of the ACL to Posix permissions.
+If you are not happy with what you see, set the permissions as you
+wish by using commands such as:
[EMAIL PROTECTED]
[EMAIL PROTECTED] ``cd /''
+
[EMAIL PROTECTED] ``chmod -R a+r .''
+
[EMAIL PROTECTED] ``chmod -R a+x bin usr/sbin usr/local/bin lib/gcc-lib usr/X11R6/bin''
[EMAIL PROTECTED] enumerate
+You can also change the group and the owner with ``chgrp -R'' and/or ``chown -R''.
+
+Note that programs executed by services (such as inetd or cron) must be executable
+by SYSTEM, which is in the ``Administrators'' and ``Everyone'' groups but not
+e.g. in ``Users'' nor in ``Authenticated Users''.
+
@subsection Can I use Cygwin Setup to update a B18, B19, B20, B20.1 or CD-ROM (1.0)
installation of Cygwin?
No, you must start from scratch with the new Cygwin Setup. The
@@ -198,14 +223,49 @@ character as a word delimiter. Under ce
possible to get around this with various shell quoting mechanisms, but
you are much better off if you can avoid the problem entirely.
-In particular, the environment variables @samp{USER} and @samp{HOME} are
-set for you in /etc/profile. By default these derive from your Windows
-logon name. You may edit this file and set them explicitly to something
-without spaces.
-
-(If you use the @samp{login} package or anything else that reads
-/etc/passwd, you may need to make corresponding changes there. See the
-README file for that package.)
+On Windows NT/2000/XP you have two choices:
[EMAIL PROTECTED]
+
[EMAIL PROTECTED] You can rename the user in the Windows User Manager GUI and then
+run mkpasswd.
+
[EMAIL PROTECTED] You can simply edit the /etc/passwd file and change the Cygwin user
name
+(first field). It's also a good idea to avoid spaces in the home directory.
+
[EMAIL PROTECTED] enumerate
+
+On Windows 95/98/ME you can create a new user and run mkpasswd,
+or you can delete the offending entry from /etc/passwd.
+Cygwin will then use the name in the default entry with uid 500.
+
[EMAIL PROTECTED] My @samp{HOME} environment variable is not what I want.
+
+When starting Cygwin from Windows, @samp{HOME} is determined as follows
+in order of decreasing priority:
+
[EMAIL PROTECTED]
+
[EMAIL PROTECTED] @samp{HOME} from the Windows environment, translated to POSIX form.
+
[EMAIL PROTECTED] The entry in /etc/passwd
+
[EMAIL PROTECTED] @samp{HOMEDRIVE} and @samp{HOMEPATH} from the Windows environment
+
[EMAIL PROTECTED] /
+
[EMAIL PROTECTED] enumerate
+
+When using Cygwin from the network (telnet, ssh,...), @samp{HOME} is set
+from /etc/passwd.
+
+If your @samp{HOME} is set to a value such as /cygdrive/c, it is likely
+that it was set in Windows. Start a DOS Command Window and type
+set HOME to verify if this is the case.
+
+Access to shared drives is often restricted when starting from the network,
+thus Domain users may wish to have a different @samp{HOME} in the
+Windows environment (on shared drive) than in /etc/passwd (on local drive).
+Note that ssh only considers /etc/passwd, disregarding @samp{HOME}.
@subsection How do I uninstall individual packages?
