Re: recent gnulib changes require coreutils adaptations
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: However, I can't reproduce that: $ git clone git://git.sv.gnu.org/coreutils.git cu \ cd cu ./bootstrap --gnulib-srcdir=/gnulib ... Creating ./._bootmp/lib/uniwidth/.gitignore ... ./bootstrap: done. Now you can run './configure'. Are you sure your copy of coreutils was up to date? Yes, I just now checked again; please see the transcript below. I notice that you bootstrapped from a private copy of gnulib; perhaps that's out of date on your host? No. I reran the following in a brand-new account on my system, as well as on another system altogether (that claims to be Debian 4.0), just to be sure: $ git clone git://git.sv.gnu.org/coreutils.git cu cd cu ./bootstrap Both times, it succeeded. However, the log showed differences from yours. Your log has the following overrides lines, while mine don't: 505-penguin $ git clone git://git.sv.gnu.org/coreutils.git cu ... ./bootstrap: build-aux/.gitignore overrides ._bootmp/build-aux/.gitignore ... ./bootstrap: doc/.gitignore overrides ._bootmp/doc/.gitignore ... ./bootstrap: lib/.gitignore overrides ._bootmp/lib/.gitignore That probably comes down to the use of version_controlled_file() in bootstrap's slurp function, and makes me wonder if our differences are due to your using a version of git for which git-rm -n file doesn't do what version_controlled_file expects it to. I've tested the following versions of git: 1.5.3.rc1.27.ga5e40 1.5.2.4 1.4.4.4 E.g., from a git-cloned coreutils work area, git-rm -n doc/.gitignore should exit successfully. Does that work for you? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segment fault rm corrupt files
On Tue, July 17, 2007 3:46 am, Bob Proulx wrote: Reg. Charney wrote: On a number of occasions, Konqueror has crashed and produced a file named something like: /tmp/kde-$USER/konqueror-crash-XX.log However, the file has an unknown type, size, and permissions. This makes no sense in the context of Unix filesystems. Please run the following command and post the output to the mailing list. You may need to adjust the file globs to match. ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log The result of this command is: [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log drwx-- 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-SQil1b.log However, this was run after I somehow deleted the invalid files since I could not reboot without eliminating these invalid files. This is a contradiction to the original bug report. The exact command that raised the segmentation fault was: rm -rf /tmp/kde-* Thus, the error may have been in the glob expansion, not in the rm command. Because I needed to delete the invalid files, I can not show you exactly what I had. However, the following was the output I that I recall I received with the ls command: [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log drwx-- 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg ?- ? reg reg? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-XYwuxw.log ?- ? reg reg? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-STuxyz.log That will show us the file type, size and permissions. Or it will have an error which will also be informative. Again, the ls command at the time could not tell me this. As part of the /etc/rc.sysinit file, I have a rm command of the form: rm -rf /tmp/kde-$USER/* Typically systems will purge the contents of /tmp on a reboot. I think Fedora does this but can't check at the moment. In which case the above command is not needed. Regardless of that the $USER is an environment variable. Inside of the /etc/rc.sysinit script that will almost certainly be root. I don't think this will match the user that was actually running konqueror at the moment that the core file was created. Therefore it will be very unlikely to actually match any files. Actually, the crash logs are related to the user using kde at the time of failure. Thus, the subdirectory is named kde-reg where I was logged in as user 'reg'. Because the type of these crash files are unknown, the rm command fails with a segment fault on my Intel IA86 machine (a MacBook running Parallels Fedora Core 6 Linux under Mac OS X (10.4)). It would be good if you could show us the exact output. I wish I could show this now, but the system was not in a state then that I could do this. Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segment fault rm corrupt files
Reg. Charney wrote: The result of this command is: [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log drwx-- 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-SQil1b.log Of course now with new files those look fine. :-( The exact command that raised the segmentation fault was: rm -rf /tmp/kde-* Thus, the error may have been in the glob expansion, not in the rm command. You might want to scan through your system logs and see if any filesystem errors are logged there. It appears that you were having some filesystem related issues and perhaps there will be a clue left behind about it there. Segmentation violations are always bugs. The problem is determining the root cause of the bug. Here it could be in the glob expansion or in system added patches. Because the rm command is fairly simple I am in a little bit of disbelief that the problem is there but it could be. the following was the output I that I recall I received with the ls command: [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log drwx-- 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg ?- ? reg reg? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-XYwuxw.log ?- ? reg reg? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-STuxyz.log This appears to indicate that the stat calls from ls to the kernel requesting filesystem information failed. The ls command reported the information that it had available. for the fields that it did not have information it reported a '?'. If the stat calls were failing then that would indicate a filesystem problem and is why I think there may be errors logged to the system log file usually /var/log/syslog or /var/log/messages or some such system dependent location. Again, the ls command at the time could not tell me this. Oh well. Because the type of these crash files are unknown, the rm command fails with a segment fault on my Intel IA86 machine (a MacBook running Parallels Fedora Core 6 Linux under Mac OS X (10.4)). It would be good if you could show us the exact output. I wish I could show this now, but the system was not in a state then that I could do this. The reason I said that was because saying the type of the files are unknown did not make sense to me since unix-like filesystems do not have file types (in the same way that older filesystems had file types). At that point I was stuck. But now with the additional information about the ls listing we now know that there were failures reported by the filesystem in response to the stat kernel filesystem calls. That is obviously not good. But it probably not a bug in coreutils, which is good for us on the coreutils list but worse for you. About all of the advice I can offer is to keep an eye on the filesystem and see if the problem returns. If the problem does return then try running 'strace' and saving the output. strace -o /tmp/strace.out ls -ld /path/to/file The strace will show the system calls and return values. If stat calls are failing this should show the information for those failures. Good luck! Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[coreutils-6.9] ls bug: ls failing to sort alphabetically with and without options
My distro is ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc). I noticed that ls was failing to sort alphabetically so I grabbed the latest version of coretuils and compiled it: ]# wget http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.gz ]# tar xvfz coreutils-6.9.tar.gz ]# cd coreutils-6.9 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[coreutils-6.9] ls and sort bug: ls and sort fails to sort alphabetically with and without options
My distro is ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc). I noticed that ls was failing to sort alphabetically so I grabbed the latest version of coreutils and compiled it to test it, which failed as well: ~]# wget http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.gz ~]# tar xvfz coreutils-6.9.tar.gz ~]# cd coreutils-6.9 coreutils-6.9]# ./configure coreutils-6.9]# make coreutils-6.9]# ldd src/ls librt.so.1 = /lib/tls/librt.so.1 (0x00111000) libc.so.6 = /lib/tls/libc.so.6 (0x00428000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0x00bda000) /lib/ld-linux.so.2 (0x00bf2000) coreutils-6.9]# src/ls -1 /var/arpwatch/ arp2ethers arp.dat arp-eth1.dat arpfetch arp-wlan0.dat d.awk duplicates.awk e.awk ethercodes.dat euppertolower.awk massagevendor massagevendor-old missingcodes.txt p.awk The same order in the output is produced by -alh(I'd imagine other options as well) as well as no options. -r produces the same order except reversed. The unsorted section is the arp* block: arp2ethers arp.dat arp-eth1.dat arpfetch arp-wlan0.dat Next I tried to pipe that through sort to see if it would come out sorted: coreutils-6.9]# src/ls -1 /var/arpwatch/ | grep arp | src/sort arp2ethers arp.dat arp-eth1.dat arpfetch arp-wlan0.dat I also tried passing various values to sort like -dfgin(not at the same time) and this had no effect on the sort order, each option looked like the output above. I would have expected the output to look like this: arp-eth1.dat arp-wlan0.dat arp.dat arp2ethers arpfetch or something similar, not the output I am currently getting. Hooroo, Wilber ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[coreutils-6.9] multiple utilities not handling escape char(\) properly when used with -, instead interpreting as option(could be a bash bug?)
ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc) I compiled the latest coreutils from source. Then I ran these series of commands: coreutils-6.9]# mkdir testdir coreutils-6.9]# cd testdir/ testdir]# ../src/touch +foo0 testdir]# ../src/touch \+foo1 testdir]# ../src/touch -bar0 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ That error is correct as the - char is used for options. testdir]# ../src/touch \-bar1 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ This is wrong, this should work!! testdir]# ../src/touch \\-bar2 ^^ Trying a double backslash to see what happens testdir]# ls +foo0 +foo1 \-bar2 ^^ It is what is expected. testdir]# ../src/touch '-bar3' ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ Trying single quotes testdir]# ../src/touch -bar4 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ Trying double quotes testdir]# ../src/mv +foo0 -bar5 ../src/mv: invalid option -- e Try `../src/mv --help' for more information. ^^ That error is correct as the - char is used for options. testdir]# ../src/mv +foo0 \-bar6 ../src/mv: invalid option -- e Try `../src/mv --help' for more information. ^^ This is wrong, this should work!! testdir]# ../src/touch ./-bar7 testdir]# ../src/touch ./\-bar8 testdir]# ls +foo0 +foo1 \-bar2 -bar7 -bar8 testdir]# As you can see from the above commands, \-barX is being interpreted as an option to touch/mv/etc instead of being part of the filename. Hooroo, Wilber ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
(no subject)
Hello, Please find following information: [EMAIL PROTECTED] u01]$ df -lkh FilesystemSize Used Avail Use% Mounted on /dev/vg00/lvol0 6.8G 347M 6.1G 6% / /dev/cciss/c0d0p1 97M 17M 76M 18% /boot none 1.8G 0 1.8G 0% /dev/shm /dev/vg00/lvol2 2.9G 785M 2.0G 28% /tmp /dev/vg00/lvol8 8.7G 7.7G 619M 93% /u01 /dev/vg00/lvol929G 23G 4.9G 83% /u02 /dev/vg00/lvol1 3.9G 2.6G 1.1G 71% /usr /dev/vg00/lvol3 2.0G 240M 1.6G 13% /var /dev/cciss/c0d167G 60G 4.4G 94% /backup [EMAIL PROTECTED] u01]$ du -lkhs /u01 5.5G/u01 [EMAIL PROTECTED] u01]$ man df [EMAIL PROTECTED] u01]$ uname -a Linux dbapp032 2.4.21-15.ELsmp #1 SMP Thu Apr 22 00:18:24 EDT 2004 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] u01]$ Note that I have deleted a 2.2 GB file , and du don't update the output table. Best regards, shabahang ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
df reporting and removing files (Re: (no subject))
Elmian Shabahang wrote: Hello, In the future please include a meaningful subject line otherwise it is likely that your message will be deleted without reading because it looks too much like spam. Please find following information: /dev/vg00/lvol8 8.7G 7.7G 619M 93% /u01 [EMAIL PROTECTED] u01]$ du -lkhs /u01 5.5G/u01 You appear to be concerned that df reports 7.7G used but du does not find it by traversing the filesystem? Is that correct? Note that I have deleted a 2.2 GB file , and du don't update the output table. That is perfectly okay. The 'df' command reports information about filesystem. The 'du' command traverses directories and reports information in directory hierarchies. Those are two different things and they may report different information. In this case it means that disk space is in use by processes but is not reachable by the directory hierarchy. Since you said that you removed the file from the directory this information is verified. The filesystem recovers disk space through garbage collection. When files are busy the disk space is in use. When the reference count for a file is reduced to zero then the filesystem recovers the disk blocks associated with the file. Removing files removes the directory pointer to that file but it does not remove the file from use by running processes. If a running process has the file open then the reference count will be non-zero due to use by that process and the filesystem will not be able to reclaim that disk space until the process exits. A typical example is a program writing a log file. The log file may grow to be quite large. As long as the process is running the reference count for that file will be non-zero. Removing the file from the directory will not free up the disk space. In fact doing so means that there is no no way to access that file again. The only way to reduce the reference count would be to kill the process that holds the file in use. To avoid this case it is better to truncate large files to free up the disk space immediately instead of removing them. Hope that helps. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Cros-Compiled binaries used by host when Cross-Compiling Coreutils.
Ulf Samuelsson wrote: When cross-compiling coreutils-6.9 for ARM from buildroot I noticed that the Makefile.am and Makefile.in are using rm, mv, chmod, chown. Yes, that is correct. Since these commands are also built in the coreutils-6.9/src, the make in this directory will use the recently built ARM binaries after they have been built instead of the coreutils on the host machine. This indicates to me that you have . in your PATH too early. What is the value of your PATH? echo $PATH Try adjusting your PATH to either remove . from it entirely (many believe it to be a security risk there) or to place it at the end of your PATH. It would be better to use /bin/rm, /bin/mv, /bin/chmod, /bin/chown when building in this directory. No, that would be incorrect. Using full hard coded paths is almost always an additional source of problems. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils-6.9] ls and sort bug: ls and sort fails to sort alphabetically with and without options
Wilber Washbucket [EMAIL PROTECTED] writes: I noticed that ls was failing to sort alphabetically Please read the answer to questions 22 and 23 in the coreutils FAQ. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021 Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils-6.9] ls and sort bug: ls and sort fails to sort alphabetically with and without options
Wilber Washbucket wrote: I noticed that ls was failing to sort alphabetically so I grabbed the latest version of coreutils and compiled it to test it, which failed as well: Thank you for your report. However your report matches a very common signature that is not a bug in coreutils but is instead simply a misunderstanding of locale. Check your locale setting. The 'locale' command may be used conveniently to print out the current settings. locale You are probably using a locale in which the character collating sequence is a dictionary sort ordering. (For example all of the en_* (english) locales sort by ignoring punctuation and folding case.) Try setting the high priority locale override to select the POSIX C locale for everything. export LC_ALL=C See this reference for more details. http://www.gnu.org/software/coreutils/faq/ Look for Sort does not sort in normal order! Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils-6.9] ls and sort bug: ls and sort fails to sort alphabetically with and without options
On Wed, 18 Jul 2007, Wilber Washbucket wrote: I noticed that ls was failing to sort alphabetically so I grabbed the latest version of coreutils and compiled it to test it, which failed as well: http://www.gnu.org/software/coreutils/faq/#The-ls-command-is-not-listing-files-in-a-normal-order_0021 The FAQ explains how locale environment setting can affect sort order, and how to change/unset them. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils-6.9] multiple utilities not handling escape char(\) properly when used with -, instead interpreting as option(could be a bash bug?)
Wilber Washbucket [EMAIL PROTECTED] writes: ClarkConnect Community Edition release 4.0 (kernel 2.6.9-42.cc) I compiled the latest coreutils from source. Then I ran these series of commands: coreutils-6.9]# mkdir testdir coreutils-6.9]# cd testdir/ testdir]# ../src/touch +foo0 testdir]# ../src/touch \+foo1 testdir]# ../src/touch -bar0 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ That error is correct as the - char is used for options. That is a variant of question 11 in the coreutils FAQ. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#How-do-I-remove-files-that-start-with-a-dash_003f testdir]# ../src/touch \-bar1 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ This is wrong, this should work!! The backslash has been removed by the shell before the touch command has seen it. Try prefixing all your tries with echo to seen the actual command line that is executed. Btw., when I try to execute that command, I get a different error: ../src/touch: invalid option -- b Try `../src/touch --help' for more information. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Cros-Compiled binaries used by host when Cross-Compiling Coreutils.
Ulf Samuelsson [EMAIL PROTECTED] writes: When cross-compiling coreutils-6.9 for ARM from buildroot I noticed that the Makefile.am and Makefile.in are using rm, mv, chmod, chown. Since these commands are also built in the coreutils-6.9/src, the make in this directory will use the recently built ARM binaries after they have been built instead of the coreutils on the host machine. That would mean that you have . in PATH. You should never do that, at least do not put it before the system paths. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [coreutils-6.9] multiple utilities not handling escape char(\) properly when used with -, instead interpreting as option(could be a bash bug?)
On Wed, 18 Jul 2007, Wilber Washbucket wrote: I compiled the latest coreutils from source. Then I ran these series of commands: coreutils-6.9]# mkdir testdir coreutils-6.9]# cd testdir/ testdir]# ../src/touch +foo0 testdir]# ../src/touch \+foo1 testdir]# ../src/touch -bar0 ../src/touch: invalid option -- e Really? There is no option e specified. Try `../src/touch --help' for more information. ^^ That error is correct as the - char is used for options. testdir]# ../src/touch \-bar1 ../src/touch: invalid option -- e Try `../src/touch --help' for more information. ^^ This is wrong, this should work!! This isn't due to coreutils, nor is really a bash bug; rather it's an artifact of how shell escaping works. Please try set +x in bash to view the commandlines after escape-processing, to see how touch is actually seeing your commands. testdir]# ../src/mv +foo0 -bar5 ../src/mv: invalid option -- e Try `../src/mv --help' for more information. ^^ That error is correct as the - char is used for options. That's a slightly different issue. coreutils are permissive in their options parsing. By setting the environment variable POSIXLY_CORRECT, this command will complete without error. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Cros-Compiled binaries used by host when Cross-Compiling Coreutils.
- Original Message - From: Bob Proulx [EMAIL PROTECTED] To: Ulf Samuelsson [EMAIL PROTECTED] Cc: bug-coreutils@gnu.org Sent: Tuesday, July 17, 2007 6:35 PM Subject: Re: Cros-Compiled binaries used by host when Cross-Compiling Coreutils. Ulf Samuelsson wrote: When cross-compiling coreutils-6.9 for ARM from buildroot I noticed that the Makefile.am and Makefile.in are using rm, mv, chmod, chown. Yes, that is correct. Since these commands are also built in the coreutils-6.9/src, the make in this directory will use the recently built ARM binaries after they have been built instead of the coreutils on the host machine. This indicates to me that you have . in your PATH too early. What is the value of your PATH? echo $PATH Try adjusting your PATH to either remove . from it entirely (many believe it to be a security risk there) or to place it at the end of your PATH. It would be better to use /bin/rm, /bin/mv, /bin/chmod, /bin/chown when building in this directory. No, that would be incorrect. Using full hard coded paths is almost always an additional source of problems. Bob I realized that the path was a problem, and I removed the . from the PATH in .bashrc but the problems remained. The makefile seems to call ./rm at some stage, and I am screwed Further checking now shows that the . remains in the PATH, so maybe I have to logout-login. . I think the best approach is that the configure script figures out what the path is to these tools and uses the path. Something like this is used in the buildroot system for other things: ifndef HOST_RM HOST_RM:=rm endif HOST_RM:=$(shell $(CONFIG_SHELL) -c which $(HOST_RM) || type -p $(HOST_RM) || echo rm) and could be used for the rm/mv/chmod/chown. Seems like make has the same problem, if you build it, then it starts to use the recent copy of make, which is not so nice for cross compilation. Best Regards Ulf Samuelsson ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Cros-Compiled binaries used by host when Cross-Compiling Coreutils.
Ulf Samuelsson [EMAIL PROTECTED] wrote: I realized that the path was a problem, and I removed the . from the PATH in .bashrc but the problems remained. The makefile seems to call ./rm at some stage, and I am screwed Further checking now shows that the . remains in the PATH, so maybe I have to logout-login. . I think the best approach is that the configure script figures out what the path is to these tools and uses the path. Something like this is used in the buildroot system for other things: ifndef HOST_RM HOST_RM:=rm endif HOST_RM:=$(shell $(CONFIG_SHELL) -c which $(HOST_RM) || type -p $(HOST_RM) || echo rm) No. Just fix your PATH (having . too early is a security risk, btw), and you'll be fine. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Segment fault rm corrupt files
Hi Bob, You are probably correct about file system corruption. I found a large number of the following type of errors: /var/log/messages.3:Jun 23 23:14:49 localhost kernel: EXT3-fs error (device dm-0): ext3_free_blocks: Freeing blocks not in datazone - block = 1315991916, count = 1 /var/log/messages.3:Jun 23 23:14:49 localhost kernel: EXT3-fs error (device dm-0): ext3_free_blocks_sb: bit already cleared for block 647337 I had not rebooted for a long time, so the corrupted files were not detected until long after the errors occurred. Again, thanks, Reg. On Tue, July 17, 2007 4:09 pm, Bob Proulx wrote: Reg. Charney wrote: The result of this command is: [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log drwx-- 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-EBXvbc.log -rw--- 1 reg reg0 Jul 16 22:02 /tmp/kde-reg/konqueror-crash-SQil1b.log Of course now with new files those look fine. :-( The exact command that raised the segmentation fault was: rm -rf /tmp/kde-* Thus, the error may have been in the glob expansion, not in the rm command. You might want to scan through your system logs and see if any filesystem errors are logged there. It appears that you were having some filesystem related issues and perhaps there will be a clue left behind about it there. Segmentation violations are always bugs. The problem is determining the root cause of the bug. Here it could be in the glob expansion or in system added patches. Because the rm command is fairly simple I am in a little bit of disbelief that the problem is there but it could be. the following was the output I that I recall I received with the ls command: [EMAIL PROTECTED] ~]# ls -ld /tmp/kde-* /tmp/kde-*/konqueror-crash-*.log drwx-- 2 reg reg 4096 Jul 16 22:02 /tmp/kde-reg ?- ? reg reg? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-XYwuxw.log ?- ? reg reg? Jul 14 22:02 /tmp/kde-reg/konqueror-crash-STuxyz.log This appears to indicate that the stat calls from ls to the kernel requesting filesystem information failed. The ls command reported the information that it had available. for the fields that it did not have information it reported a '?'. If the stat calls were failing then that would indicate a filesystem problem and is why I think there may be errors logged to the system log file usually /var/log/syslog or /var/log/messages or some such system dependent location. Again, the ls command at the time could not tell me this. Oh well. Because the type of these crash files are unknown, the rm command fails with a segment fault on my Intel IA86 machine (a MacBook running Parallels Fedora Core 6 Linux under Mac OS X (10.4)). It would be good if you could show us the exact output. I wish I could show this now, but the system was not in a state then that I could do this. The reason I said that was because saying the type of the files are unknown did not make sense to me since unix-like filesystems do not have file types (in the same way that older filesystems had file types). At that point I was stuck. But now with the additional information about the ls listing we now know that there were failures reported by the filesystem in response to the stat kernel filesystem calls. That is obviously not good. But it probably not a bug in coreutils, which is good for us on the coreutils list but worse for you. About all of the advice I can offer is to keep an eye on the filesystem and see if the problem returns. If the problem does return then try running 'strace' and saving the output. strace -o /tmp/strace.out ls -ld /path/to/file The strace will show the system calls and return values. If stat calls are failing this should show the information for those failures. Good luck! Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
