[PATCH] Adding information to README
[[[ Provide addition information helpful in the construction of the APR using Subversion. * README Added hints on building APR using Subversion. Patch by: L. Perkins ]]] Thank-you, Luke Perkins 2581 Flagstone Drive San Jose, California 95132-2611 Cell: 719-339-0987 Home: 408-457-1857 ProposedChanged_201702052044.diff Description: Binary data
apr_sockaddr_info_get;Need some information
Hi all, I am writing a client program to connect to the server and I want my code to support both IPV4 and IPV6 addresses and henceforth I am using the APR calls as APR internal takes care of it. The issues I am facing are: 1> The apr_sockaddr_info_get () goes fine if I specify the hostname( myserver.domain.com) with APR_UNSPEC, but the same thing fails when I specify the IP address in dotted format in place of hostname. apr_sockaddr_info_get(&sa, hostname, APR_UNSPEC, port, APR_IPV4_ADDR_OK, mypool); 2> Are there any equivalent APR calls similar to inet_addr() and inet_ntoa() and gethostbyname()? i.e to convert network address to IP and vice versa and also hostname to IP address mapping. Can some one please guide me to write a simple client program thats handles both IPV4 and IPV6 address and also how to resolve a given hostname/IP address? -- With Regards, Raj
APR - Information
I am very interested in the Apache Portable Runtime Project (APR). Platform independence is an ambitious goal and I commend you on taking up the challenge. The issue of platform independence is becoming an increasingly important one in much of my work. Ive looked into several efforts that facilitate the ability to write one application which will run on multiple platforms and the APR seems to be among the most advanced. I am considering using the APR for a project, but a number of issues related to platform independence and the strategy and design goals of the APR have arisen in some discussions. Ive read through the documentation and some of the mail list archives, but I still have some questions. Any answers you can provide to any of these questions will be greatly appreciated, and will go a long way in aiding my decision of whether APR can be of use. Questions: How does the performance of applications written to the APR API compare to application written to the native platform API? In terms of size and speed? Other organizations, such as Netscape, have tried to build similar platform abstraction systems but have had mixed results, and concluded that some systems built to these frameworks are not efficient enough for use in deployed production systems. Still other attempts at a unified platform, such as POSIX, have achieved limited success, how is APR different? Has anyone looked at similar commercial or open source products such as QT or ACE? How does APR compare to these products? How complete is the platform abstraction is achieved by APR? ie. Which interfaces are still native now, and what is the long term plan? Are only server-side OSs going to be supported, or are desktop and embedded OS platforms going to be supported as well? Are there any plans for GUI support -- related to desktop question above? If so, will this preserves the look and feel of the particular platform or is there an APR look and feel that will be consistent for all applications? The web page describes that developers be assured of predictable if not identical behaviour. What functionality does not provide identical behavior on all platforms? How are these compromises chosen? Is support for a particular application the test, i.e. Apache? How are type and endian platform difference issues resolved? Does APR have a preferred representation for types? Does this give preference to certain platforms? I.E. does APR define a platform independent representation used by all supported platforms? Network Byte Order? Does APR implement the IEEE 754 floating point standard? Will APR support language bindings other than C? e.g. Java? Thanks for any answers, David Viel Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/
Re: information
I study Computer Sciences and actually work on a tutorial on APR programming. As soon as is gets shape I'll publish it here (I think in about two weeks). This might help you. Best regards, Klaus Charles Bonello schrieb: Dear sir/madam I am a student studying business studies at school and I would like some information about APR. Would you please forward some information. Thanks in advance. Regards Julian Bonello Malta
Re: information
On Sun, 11 Jan 2004, Charles Bonello wrote: > I am a student studying business studies at school and I would like some > information about APR. Would you please forward some information. Have you seen our website at http://apr.apache.org/ ? What additional information would you like to know? --Cliff
information
Dear sir/madam I am a student studying business studies at school and I would like some information about APR. Would you please forward some information. Thanks in advance. Regards Julian Bonello Malta
RedHat Linux 7.1 Problem apr (More information 2)
This is the output of the program testsock in the test directory. I have enclose between ** what it seems starnge to me. >./testsock Initializing.OK Creating context...OK This test relies on the process test working. Please run that test first, and only run this test when it completes successfully. Alternatively, you could run server and client by yourself. Creating children to run network tests... server: Initializing OK server: Creating context OK server: Preparing getopt OK server: Creating new socket. OK server: Setting option APR_SO_NONBLOCK.. OK server: Setting option APR_SO_REUSEADDR. OK server: Binding socket to port.. OK server: Listening to socket. OK server: Setting up for polling.. OK Initializing.OK Creating context...OK Client: Making socket address...OK Client: Creating new socket...OK Client: Setting socket timeout...OK Client: Connecting to socket...OK Client socket: 127.0.0.1:43847 -> 127.0.0.1:8021 Client: Trying to send data over socket...OK Client: Trying to receive data over socket...server: Polling for socket.. OK server: Accepting a connection.. OK Server socket: 127.0.0.1:8021 -> 127.0.0.1:43847 server: Receiving data from socket.. OK OK Client: Shutting down socket...OK Client: Closing down socket...OK server: Sending data over socket OK server: Shutting down accepted socket... OK server: Closing duplicate socket OK server: Closing original socket. OK Network test completed. Creating children to run network tests... Waiting for a client to connect... Creating a test file... Sending the file... Processing a client... apr_socket_sendfile() updated offset with 0 apr_socket_sendfile() updated len with 370049 bytes really sent: 370049 After apr_socket_sendfile(), the kernel file pointer is at offset 0. server: apr_socket_sendfile() worked as expected! client: apr_socket_sendfile() worked as expected! Network test completed. Creating children to run network tests... Waiting for a client to connect... Creating a test file... Sending the file... Calling apr_socket_sendfile()... Headers (3): 15 bytes (1) 5 bytes (E) 8 bytes (^) File: 20 bytes from offset 0 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->0, sent 65532 bytes Calling apr_socket_sendfile()... Headers (1): 14488 bytes (^) File: 20 bytes from offset 0 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->0, sent 81921 bytes Calling apr_socket_sendfile()... Headers (0): File: 132567 bytes from offset 67433 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->11, sent 0 bytes Processing a client... Calling apr_socket_sendfile()... Headers (0): File: 132567 bytes from offset 67433 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->0, sent 49152 bytes Calling apr_socket_sendfile()... Headers (0): File: 83415 bytes from offset 116585 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->11, sent 0 bytes Calling apr_socket_sendfile()... Headers (0): File: 83415 bytes from offset 116585 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->0, sent 49152 bytes Calling apr_socket_sendfile()... Headers (0): File: 34263 bytes from offset 165737 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->11, sent 0 bytes Calling apr_socket_sendfile()... Headers (0): File: 34263 bytes from offset 165737 Trailers (3): 19 bytes 10 bytes 9 bytes apr_socket_sendfile()->0, sent 49152 bytes Calling apr_socket_sendfile()... Headers (0): File: 0 bytes from offset 0 Trailers (1): 75140 bytes apr_socket_sendfile()->11, sent 0 bytes Calling apr_socket_sendfile()... Headers (0): File: 0 bytes from offset 0 Trailers (1): 75140 bytes apr_socket_sendfile()->0, sent 49152 bytes Calling apr_socket_sendfile()... Headers (0): File: 0 bytes from offset 0 Trailers (1): 25988 bytes apr_socket_sendfile()->11, sent 0 bytes Calling apr_socket_sendfile()... Headers (0): File: 0 bytes from offset 0 Trailers (1): 25988 bytes apr_socket_sendfile()->0, sent 25988 bytes After apr_socket_sendfile(), the kernel file pointer is at offset 0. ***apr_socket_recv()->11/Resource temporarily unavailable (expected APR_EOF)*** Network test completed. Creating children to run network tests... Waiting for a client to connect... Creating a test file... Sending the file... Calling apr_socket_sendfile()... Headers (3):
RedHat Linux 7.1 Problem apr (More information)
Hi all, I run the test inside test directory and I noticed this two error: > ./testall -v testsockets Partial APR Tests: Socket Creation: ..FFF. 6 tests run: 3 passed, 3 failed, 0 not implemented. Failed tests in Socket Creation: 1) tcp6_socket: expected <0> but was <97> 2) udp6_socket: expected <0> but was <97> 3) sendto_receivefrom: expected <0> but was <97> > ./testall -v testtime Partial APR Tests: Time: ..FF 12 tests run: 10 passed, 2 failed, 0 not implemented. Failed tests in Time: 1) test_localstr: expected > 2002-08-14 12:05:36.186711 -25200 [257 Sat] DST < but saw > 2002-08-14 21:05:36.186711 +7200 [257 Sat] DST < 2) test_ctime: expected > Sat Sep 14 12:05:36 2002 < but saw > Sat Sep 14 21:05:36 2002 < 50% of testsockets fails! Can someone help me? Thanks --Marco
Re: [PATCH] apr_dir_read doesn't return requested information
As much as I agree 0 might be a valid inode... I strongly suspect that 0 would be reserved for the boot sector or other filesystem tables. I'm not too worried that 0 is a valid file of anything other than '/' Bill At 07:19 PM 12/18/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote: >William A. Rowe, Jr. wrote: > >>At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote: >> >> >>>At 08:14 AM 12/18/2002, Philip Martin wrote: >>> >>> >>>>This is for dir.c version 1.71 with the patch reverted. The >>>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c, >>>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first >>>>two calls to apr_dir_read return "." and ".." and the Subversion code >>>>skips them, the following gdb information is for the third call >>>> >>>> >> >>,,, never mind my earlier questions. Committed a patch to ignore the >>results of d_type when it's DT_UNKNOWN (or a code we don't grok) >>and ignore the results of d_fileno/d_ino when the value is 0 or -1. >> >> >Yes, I'd figured on something like that being the correct fix. But I'm >not sure what to use as an invalid inode number; -1 almost certainly, >but I have a horrible suspicion that 0 might be a valid inode. > >-- >Brane Čibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
William A. Rowe, Jr. wrote: >At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote: > > >>At 08:14 AM 12/18/2002, Philip Martin wrote: >> >> >>>This is for dir.c version 1.71 with the patch reverted. The >>>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c, >>>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first >>>two calls to apr_dir_read return "." and ".." and the Subversion code >>>skips them, the following gdb information is for the third call >>> >>> > >,,, never mind my earlier questions. Committed a patch to ignore the >results of d_type when it's DT_UNKNOWN (or a code we don't grok) >and ignore the results of d_fileno/d_ino when the value is 0 or -1. > > Yes, I'd figured on something like that being the correct fix. But I'm not sure what to use as an invalid inode number; -1 almost certainly, but I have a horrible suspicion that 0 might be a valid inode. -- Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
At 11:48 AM 12/18/2002, William A. Rowe, Jr. wrote: >At 08:14 AM 12/18/2002, Philip Martin wrote: >> >>This is for dir.c version 1.71 with the patch reverted. The >>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c, >>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first >>two calls to apr_dir_read return "." and ".." and the Subversion code >>skips them, the following gdb information is for the third call ,,, never mind my earlier questions. Committed a patch to ignore the results of d_type when it's DT_UNKNOWN (or a code we don't grok) and ignore the results of d_fileno/d_ino when the value is 0 or -1. Bill
Re: [PATCH] apr_dir_read doesn't return requested information
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> Philip... thanks.
>
> Now for the oddball question, looking at dirent.h or it's associate sys/
> includes, what symbol DT_xxx (DT_REG, etc) do you find for value 0?
/usr/include/dirent.h
/* File types for `d_type'. */
enum
{
DT_UNKNOWN = 0,
# define DT_UNKNOWN DT_UNKNOWN
DT_FIFO = 1,
# define DT_FIFODT_FIFO
DT_CHR = 2,
# define DT_CHR DT_CHR
DT_DIR = 4,
# define DT_DIR DT_DIR
DT_BLK = 6,
# define DT_BLK DT_BLK
DT_REG = 8,
# define DT_REG DT_REG
DT_LNK = 10,
# define DT_LNK DT_LNK
DT_SOCK = 12,
# define DT_SOCKDT_SOCK
DT_WHT = 14
# define DT_WHT DT_WHT
};
> Also, what values do you have for DIRENT_TYPE, DIRENT_INODE from
> apr/include/arch/unix/apr_private.h?
#define DIRENT_INODE d_fileno
#define DIRENT_TYPE d_type
>From the libc info files:
`unsigned char d_type'
This is the type of the file, possibly unknown. The
following constants are defined for its value:
`DT_UNKNOWN'
The type is unknown. On some systems this is the only
value returned.
A test program:
$ cat z.c
#include
#include
int main() {
DIR *d = opendir(".");
struct dirent e, *r;
int v = readdir_r(d, &e, &r);
while (! v && r) {
printf("%s %d\n", r->d_name, r->d_type);
v = readdir_r(d, &e, &r);
}
return 0;
}
$ gcc -o z z.c
$ ls -l
total 13
drwxr-sr-x2 pm pm 48 Dec 18 18:21 foo
-rwxr-xr-x1 pm pm 5147 Dec 18 18:22 z
-rw-r--r--1 pm pm262 Dec 18 18:22 z.c
$ ./z
. 0
.. 0
z 0
foo 0
z.c 0
--
Philip Martin
Re: [PATCH] apr_dir_read doesn't return requested information
At 08:14 AM 12/18/2002, Philip Martin wrote:
>"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
>
>> What I would like to know (if you can track it...)
>>
>> Is it possible to dump the finfo structure within gdb at the point this
>> request fails? I'd pay especially close attention to the .valid bits, since
>> those are the identifiers that will help us determine if stat() was also
>> called later.
>
>This is for dir.c version 1.71 with the patch reverted. The
>Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
>it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
>two calls to apr_dir_read return "." and ".." and the Subversion code
>skips them, the following gdb information is for the third call
>
>(gdb) s
>apr_dir_read (finfo=0xb660, wanted=33587200, thedir=0x809a878) at dir.c:174
>174 apr_status_t ret = 0;
>(gdb) n
>179 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);
>(gdb)
>184 if(!ret && thedir->entry != retent)
>(gdb) p ret
>$1 = 0
>(gdb) p thedir->entry[0]
>$2 = {d_ino = 186434, d_off = 13512064, d_reclen = 16, d_type = 0 '\0',
> d_name = "..", '\0' }
Philip... thanks.
Now for the oddball question, looking at dirent.h or it's associate sys/
includes, what symbol DT_xxx (DT_REG, etc) do you find for value 0?
Also, what values do you have for DIRENT_TYPE, DIRENT_INODE from
apr/include/arch/unix/apr_private.h?
Thanks again,
Bill
Re: [PATCH] apr_dir_read doesn't return requested information
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> What I would like to know (if you can track it...)
>
> Is it possible to dump the finfo structure within gdb at the point this
> request fails? I'd pay especially close attention to the .valid bits, since
> those are the identifiers that will help us determine if stat() was also
> called later.
This is for dir.c version 1.71 with the patch reverted. The
Subversion code is svn_io_get_dirents in subversion/libsvn_subr/io.c,
it passes APR_FINFO_TYPE | APR_FINFO_NAME to apr_dir_read. The first
two calls to apr_dir_read return "." and ".." and the Subversion code
skips them, the following gdb information is for the third call
(gdb) s
apr_dir_read (finfo=0xb660, wanted=33587200, thedir=0x809a878) at dir.c:174
174 apr_status_t ret = 0;
(gdb) n
179 ret = readdir_r(thedir->dirstruct, thedir->entry, &retent);
(gdb)
184 if(!ret && thedir->entry != retent)
(gdb) p ret
$1 = 0
(gdb) p thedir->entry[0]
$2 = {d_ino = 186434, d_off = 13512064, d_reclen = 16, d_type = 0 '\0',
d_name = "..", '\0' }
(gdb) n
194 if (ret == EINVAL) {
(gdb)
214 finfo->fname = NULL;
(gdb)
216 if (ret) {
(gdb)
222 wanted &= ~APR_FINFO_INODE;
(gdb) p/x wanted
$3 = 0x2008000
(gdb) n
225 wanted &= ~APR_FINFO_TYPE;
(gdb)
228 wanted &= ~APR_FINFO_NAME;
(gdb)
230 if (wanted)
(gdb) p wanted
$4 = 0
(gdb) n
244 if (wanted && (ret == APR_SUCCESS || ret == APR_INCOMPLETE)) {
(gdb)
251 finfo->pool = thedir->pool;
(gdb)
252 finfo->valid = 0;
(gdb)
254 finfo->filetype =
filetype_from_dirent_type(thedir->entry->DIRENT_TYPE);
(gdb)
255 finfo->valid |= APR_FINFO_TYPE;
(gdb) p finfo->filetype
$5 = APR_UNKFILE
(gdb) n
258 finfo->inode = thedir->entry->DIRENT_INODE;
(gdb)
259 finfo->valid |= APR_FINFO_INODE;
(gdb)
263 finfo->name = apr_pstrdup(thedir->pool, thedir->entry->d_name);
(gdb)
264 finfo->valid |= APR_FINFO_NAME;
(gdb)
266 if (wanted)
(gdb)
269 return APR_SUCCESS;
(gdb)
Subversion explicitly requests APR_FINFO_TYPE but then the
apr_dir_read code clears that bit and so doesn't call apr_lstat.
APR_UNKFILE appears to be correct for d_type of 0, but is not a very
useful thing for APR to return in response to APR_FINFO_TYPE. It's a
change in APR's behaviour and it breaks Subversion.
--
Philip Martin
Re: [PATCH] apr_dir_read doesn't return requested information
At 10:42 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote: >Obviously, the type at least did not make it into the fle info. Looking >at this code again, the patch may indeed be wrong; but I find it really, >really hard to follow that code. In fact, I can't understand it at all. >If you can enlighten me about what's happening there, I may be able to >come up with a better patch. What I would like to know (if you can track it...) Is it possible to dump the finfo structure within gdb at the point this request fails? I'd pay especially close attention to the .valid bits, since those are the identifiers that will help us determine if stat() was also called later. First; the definition of all the apr_file_info...() fn's is to return *ALL* of the available information. If more information is available (without extra effort) than the user requests, that is always OK. If some 'extra step' must be performed on a given platfrom (e.g. win32 can't just get an inode/dev without drilling with an open file handle), then we *must* perform that extra step. I'm very interested in what is returned in .filetype. The definition of d_type is to spell out what info is available about the file directory entry. This is an lstat() style info (that is, the file doesn't reside in a directory, the link to the file does.) >I reverted my change, but be aware that apr_dir_read is currently >broken. It simply does not work on Linux with a redent glibc, it also >doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed. Thanks... If you can spell out how we called apr_dir_read it might help me a ton. I'm actively interested in helping debug the issue with the right fix. A.F.A rbb's complaint; if this code is difficult to read, by all means we should refactor for clarity. However, there is no reason *not* to deal with ALL of the information we can recover from struct dirent, if it proves reliable. I strongly suspect we are looking for some unrelated datum that we 1) didn't request, or 2) recovered an APR_INCOMPLETE because some bit was requested that can't be recovered on the platform in question. Or 3) there is some very obvious, fat fingered mistake of mine in the code. Bill
Re: [PATCH] apr_dir_read doesn't return requested information
William A. Rowe, Jr. wrote: >I'm sorry... this patch dir not come through to [EMAIL PROTECTED] for me today >(although I watched for it...) but it's simply WRONG. > > > >At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote: > > >>>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 - 1.69 >>>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 - >>>@@ -218,10 +218,10 @@ >>>return ret; >>>} >>> >>>-#ifdef DIRENT_INODE >>>+#ifndef DIRENT_INODE >>>wanted &= ~APR_FINFO_INODE; >>>#endif >>> >>> > >Old logic; if we have an INODE from dirent, we don't care that we >want an INODE from stat() because we already have the INODE. > >New Logic: if we don't have an INODE, we won't ask for an INODE >from stat(). > >I'm sorry, but that's just broken. >' >Please revert and (re)post the original description of the problem. > >If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME >that is *ALL* you are promised... we do NOT stat for info you don't ask for. > >Bill > Here's the original report: >Philip Martin <[EMAIL PROTECTED]> writes: > > > >>> Eeek! >>> >>> I've just upgraded to apache/apr/apr-util to HEAD and now I can >>> reproduce this. >>> >>> $ svnadmin create repo >>> $ svn mkdir file://`pwd`/repo/foo >>> $ svn co file://`pwd`/repo wc >>> $ svn up wc >>> ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0) >>> svn: Obstructed update >>> svn: The entry 'bar' is no longer a directory, >>> which prevents proper updates. >>> Please remove this entry and try updating again. >> >> > >Looks like a recent apr change causes apr_dir_read to fail to return >all the requested information. I don't know if this is complete from >an apr point of view, but it's sufficient to get Subversion working on >my glibc 2.2.5 Linux machine. > > >Index: apr/file_io/unix/dir.c >=== >RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v >retrieving revision 1.69 >diff -u -r1.69 dir.c >--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 - 1.69 >+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 - >@@ -218,10 +218,10 @@ > return ret; > } > >-#ifdef DIRENT_INODE >+#ifndef DIRENT_INODE > wanted &= ~APR_FINFO_INODE; > #endif >-#ifdef DIRENT_TYPE >+#ifndef DIRENT_TYPE > wanted &= ~APR_FINFO_TYPE; > #endif > > -- Philip Martin > Obviously, the type at least did not make it into the fle info. Looking at this code again, the patch may indeed be wrong; but I find it really, really hard to follow that code. In fact, I can't understand it at all. If you can enlighten me about what's happening there, I may be able to come up with a better patch. I reverted my change, but be aware that apr_dir_read is currently broken. It simply does not work on Linux with a redent glibc, it also doesn't work in Solaris 7 (at least for me), etc. etc. It must be fixed. -- Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
Re: [PATCH] apr_dir_read doesn't return requested information
On Tue, 17 Dec 2002, William A. Rowe, Jr. wrote: > I'm sorry... this patch dir not come through to [EMAIL PROTECTED] for me today > (although I watched for it...) but it's simply WRONG. > > At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote: > >>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 - 1.69 > >>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 - > >>@@ -218,10 +218,10 @@ > >> return ret; > >> } > >> > >>-#ifdef DIRENT_INODE > >>+#ifndef DIRENT_INODE > >> wanted &= ~APR_FINFO_INODE; > >> #endif > > Old logic; if we have an INODE from dirent, we don't care that we > want an INODE from stat() because we already have the INODE. > > New Logic: if we don't have an INODE, we won't ask for an INODE > from stat(). > > I'm sorry, but that's just broken. > ' > Please revert and (re)post the original description of the problem. > > If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME > that is *ALL* you are promised... we do NOT stat for info you don't ask for. Am I the only person who believes that our stat API is incredibly complex and over-engineered? If I am, I will drop it, but if I'm not can we take the time to fix it? Ryan
Re: [PATCH] apr_dir_read doesn't return requested information
I'm sorry... this patch dir not come through to [EMAIL PROTECTED] for me today (although I watched for it...) but it's simply WRONG. At 07:04 PM 12/17/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote: >>--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 - 1.69 >>+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 - >>@@ -218,10 +218,10 @@ >> return ret; >> } >> >>-#ifdef DIRENT_INODE >>+#ifndef DIRENT_INODE >> wanted &= ~APR_FINFO_INODE; >> #endif Old logic; if we have an INODE from dirent, we don't care that we want an INODE from stat() because we already have the INODE. New Logic: if we don't have an INODE, we won't ask for an INODE from stat(). I'm sorry, but that's just broken. ' Please revert and (re)post the original description of the problem. If you pass APR_FINFO_TYPE | APR_FINFO_INDOE | APR_FINFO_NAME that is *ALL* you are promised... we do NOT stat for info you don't ask for. Bill
Re: [PATCH] apr_dir_read doesn't return requested information
Philip Martin wrote: >Philip Martin <[EMAIL PROTECTED]> writes: > > > >>Eeek! >> >>I've just upgraded to apache/apr/apr-util to HEAD and now I can >>reproduce this. >> >>$ svnadmin create repo >>$ svn mkdir file://`pwd`/repo/foo >>$ svn co file://`pwd`/repo wc >>$ svn up wc >>../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0) >>svn: Obstructed update >>svn: The entry 'bar' is no longer a directory, >>which prevents proper updates. >>Please remove this entry and try updating again. >> >> > >Looks like a recent apr change causes apr_dir_read to fail to return >all the requested information. I don't know if this is complete from >an apr point of view, but it's sufficient to get Subversion working on >my glibc 2.2.5 Linux machine. > > >Index: apr/file_io/unix/dir.c >=== >RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v >retrieving revision 1.69 >diff -u -r1.69 dir.c >--- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 - 1.69 >+++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 - >@@ -218,10 +218,10 @@ > return ret; > } > >-#ifdef DIRENT_INODE >+#ifndef DIRENT_INODE > wanted &= ~APR_FINFO_INODE; > #endif >-#ifdef DIRENT_TYPE >+#ifndef DIRENT_TYPE > wanted &= ~APR_FINFO_TYPE; > #endif > > > Yup, your patch fixes my problem, too. Committed in version 1.70. Thanks! -- Brane Äibej <[EMAIL PROTECTED]> http://www.xbc.nu/brane/
[PATCH] apr_dir_read doesn't return requested information
Philip Martin <[EMAIL PROTECTED]> writes: > Eeek! > > I've just upgraded to apache/apr/apr-util to HEAD and now I can > reproduce this. > > $ svnadmin create repo > $ svn mkdir file://`pwd`/repo/foo > $ svn co file://`pwd`/repo wc > $ svn up wc > ../svn/subversion/libsvn_wc/adm_crawler.c:315: (apr_err=155000, src_err=0) > svn: Obstructed update > svn: The entry 'bar' is no longer a directory, > which prevents proper updates. > Please remove this entry and try updating again. Looks like a recent apr change causes apr_dir_read to fail to return all the requested information. I don't know if this is complete from an apr point of view, but it's sufficient to get Subversion working on my glibc 2.2.5 Linux machine. Index: apr/file_io/unix/dir.c === RCS file: /home/cvspublic/apr/file_io/unix/dir.c,v retrieving revision 1.69 diff -u -r1.69 dir.c --- apr/file_io/unix/dir.c 15 Dec 2002 05:17:51 - 1.69 +++ apr/file_io/unix/dir.c 17 Dec 2002 00:49:35 - @@ -218,10 +218,10 @@ return ret; } -#ifdef DIRENT_INODE +#ifndef DIRENT_INODE wanted &= ~APR_FINFO_INODE; #endif -#ifdef DIRENT_TYPE +#ifndef DIRENT_TYPE wanted &= ~APR_FINFO_TYPE; #endif -- Philip Martin
Re: Getting Disk information
On Tuesday 20 November 2001 12:39 pm, Doug MacEachern wrote: Careful looking at the source though. :-) It is GPL'ed, which means that any code you use from it can't be put in APR. Other than that, great catch Doug! Ryan > have a look at libgtop: > http://home-of-linux.org/gnome/libgtop/ > > it is meant to be a cross-platform api for info you'd normally see with > top, df, netstat, uptime, etc. the concept is great, but i've only had > success on linux and quite a struggle on solaris. i've heard it works > fine on freebsd. there is no win32 support. > > not sure what the status of the project is, it hasn't been updated in > quite a while. an apr-based version of the libgtop concept would be a > hellava nice library to have. -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Getting Disk information
have a look at libgtop: http://home-of-linux.org/gnome/libgtop/ it is meant to be a cross-platform api for info you'd normally see with top, df, netstat, uptime, etc. the concept is great, but i've only had success on linux and quite a struggle on solaris. i've heard it works fine on freebsd. there is no win32 support. not sure what the status of the project is, it hasn't been updated in quite a while. an apr-based version of the libgtop concept would be a hellava nice library to have.
Re: Getting Disk information
On Monday 19 November 2001 12:51 am, Rohan Nandode wrote: > Hi All, > > Is there any API(s) provided by APR library > which gives infomation/statistics about a > Disk? > I want "Free disk space" and "Total disk > space" of the hard disk. > > Please, let me know how I can do this! Those APIs don't exist yet, but they are a good idea. If you want to create a patch, I will review it, and try to commit it. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Getting Disk information
On Mon, Nov 19, 2001 at 12:51:02AM -0800, Rohan Nandode wrote: > Hi All, > > Is there any API(s) provided by APR library > which gives infomation/statistics about a > Disk? > I want "Free disk space" and "Total disk > space" of the hard disk. APR does not provide these APIs, sorry. Patches welcome :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Getting Disk information
Hi All, Is there any API(s) provided by APR library which gives infomation/statistics about a Disk? I want "Free disk space" and "Total disk space" of the hard disk. Please, let me know how I can do this! Thanks a lot! Rohan. __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com
