Checking the clean bit of a filesystem
Hello, Does anyone know the easiest way, besides running fsck, to check the clean bit on a filesystem? I need to check if a filesystem is marked clean and I do not want to call fsck. If there is not a way through userland commands to check the clean bit, can someone point me in the general direction of where this bit is set (variable name in some structure, etc). Thanks. -- Justin Hopper [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cvsup Handbook Example
Sorry, this of course should have read 'after 665 and before 667'. On Fri, 2003-02-21 at 11:13, Justin Hopper wrote: Hello unamed person, For the rest of the world that doesn't follow Christian Mythology, 666 is just the number after 667 and before 665. I've used 666 in several coding examples, usually for client/server socket daemons, as most people don't have anything using port 666. Would you rather that the good people of FreeBSD be barred from using particular numbers? This could pose a problem. -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Cvsup Handbook Example
Hello zerotransfer, I've always enjoyed religious debates, but the list probably tires of them, and if we keep this up, one of the list admins will probably tell us to 'take it outside'. But as a final followup, there are sacred numbers in every religion, as far as I know, and if we in the IT sector, which is very number heavy, paid attention to what superstition somebody may hold with a certain number, our jobs would become ever more complicated. I don't mean to belittle your religion, but I can't imagine what life must be like to be offended by such a trivial thing as a certain number =) -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com On Fri, 2003-02-21 at 13:15, [EMAIL PROTECTED] wrote: Obviously I don't think it is mythology or I wouldn't believe it :-) Actually it is not my place to tell people what numbers they are and are not allowed to use. More than the number, the issue for me is the motivation of why that number was used. Why use one of the only three digit numbers that I know of that is associated with evil to at least one belief? See my point? zerotransfer - Original Message - From: Justin Hopper [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 21, 2003 2:42 PM Subject: Re: Cvsup Handbook Example Sorry, this of course should have read 'after 665 and before 667'. On Fri, 2003-02-21 at 11:13, Justin Hopper wrote: Hello unamed person, For the rest of the world that doesn't follow Christian Mythology, 666 is just the number after 667 and before 665. I've used 666 in several coding examples, usually for client/server socket daemons, as most people don't have anything using port 666. Would you rather that the good people of FreeBSD be barred from using particular numbers? This could pose a problem. -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the me ssage To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Mysterious problem with ldconfig and ld
When running ldconfig, it saves the information in the /var/run/ld-elf.so.hints file, and I assume that ld should then know where libraries are located, since they are in this cache file. So when running: ld -lexpat, why did ld not know the location of the expat library, when it is in the cache (hints) file? -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com ---BeginMessage--- In the last episode (Jan 03), Justin Hopper said: Hmmm, I guess I just assumed that since ldconfig had cached the absolute path to the library, ld would not need to know the library path as well, but for some reason it did. What ultimately fixed the problem was hardcoding the -L /usr/local/lib in the configure script, since it refused to pick up that directory any other way. Thanks for your help. As a point of curiosity, I'd still like to know why ld would still need the -L /usr/local/lib if the full path to the library is already in the cache? what cache? ld and the run-time linker are separate entities and share no inrofmation. -- Dan Nelson [EMAIL PROTECTED] ---End Message---
Mysterious problem with ldconfig and ld
This may be a very simple fix, but so far I've found no solution. Just installed expat-1.95.5 in a FreeBSD 4.4 machine. The install went fine, and I verified that ldconfig had picked up the library: host# ldconfig -r | grep expat 73:-lexpat.4 = /usr/local/lib/libexpat.so.4 However, I need to install other packages that require the expat library, and the configuration fails stating that the expat library cannot be found. In fact, just a simple test fails: host# ld -lexpat /usr/libexec/elf/ld: cannot find -lexpat I made sure any previous installations of expat were nuked and all files deleted. And the /usr/local/lib/libexpat.so.4 does exist: higherinnovation# ll /usr/local/lib/libexpat.so.4 -rwxr-xr-x 1 root wheel 294728 Jan 3 19:44 /usr/local/lib/libexpat.so.4 If ldconfig has an entry for the library and is pointing correctly, what is the problem? Maybe I've just been staring at this for too long. Any help would be appreciated. -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Mysterious problem with ldconfig and ld
Hmmm, I guess I just assumed that since ldconfig had cached the absolute path to the library, ld would not need to know the library path as well, but for some reason it did. What ultimately fixed the problem was hardcoding the -L /usr/local/lib in the configure script, since it refused to pick up that directory any other way. Thanks for your help. As a point of curiosity, I'd still like to know why ld would still need the -L /usr/local/lib if the full path to the library is already in the cache? -- Justin Hopper [EMAIL PROTECTED] UNIX Systems Engineer http://www.spry.com ---BeginMessage--- This may be a very simple fix, but so far I've found no solution. Just installed expat-1.95.5 in a FreeBSD 4.4 machine. The install went fine, and I verified that ldconfig had picked up the library: host# ldconfig -r | grep expat 73:-lexpat.4 = /usr/local/lib/libexpat.so.4 However, I need to install other packages that require the expat library, and the configuration fails stating that the expat library cannot be found. In fact, just a simple test fails: host# ld -lexpat /usr/libexec/elf/ld: cannot find -lexpat How about ld -L/usr/local/lib -lexpat? Works fine here: gabby# ld -L /usr/local/lib -lexpat /usr/libexec/elf/ld: warning: cannot find entry symbol _start; not setting start address /usr/local/lib/libexpat.so: undefined reference to `memmove' /usr/local/lib/libexpat.so: undefined reference to `memcpy' /usr/local/lib/libexpat.so: undefined reference to `malloc' /usr/local/lib/libexpat.so: undefined reference to `realloc' /usr/local/lib/libexpat.so: undefined reference to `memset' /usr/local/lib/libexpat.so: undefined reference to `free' gabby# If some programs can't find it, it's probably because /usr/local/lib isn't in their search path. -- Matt Emmerton ---End Message---
