Re: cp -p fails from zfs file system to other file system
Excerpts from jlm's message of Wed Feb 03 22:38:33 -0500 2010: Fabrizio Gabbiani wrote: cp: preserving permissions for `/localdirectory/targetfile': Operation not supported This is likely a consequence of the recent ACL related changes. (cp -p now attempts to copy the ACLs.) I suspect this is the same issue I was seeing[1]. The patch I submitted doesn't apply to the git repo though. I was working from a tarball at the time and didn't realize how different that looked from the git master branch. I have an updated (for the 8.4 tarball) version available if it's useful, but haven't had the time to properly patch it into git for resubmission. HTH. -Ben [1] http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg00319.html -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 signature.asc Description: PGP signature
BUG: date 7.1 - reading date string
Dear coreutils-team, I used the command date -d $DATE for almost all dates between Aug 2002 end Jan 2010 in a script. Date has a format like this 2003-03-30 02:08:17 However, 7 of 42048 randomly distributed dates in the list failed: date: ungültiges Datum „2003-03-30 02:08:17“ date: ungültiges Datum „2003-03-30 02:25:58“ date: ungültiges Datum „2005-03-27 02:08:41“ date: ungültiges Datum „2006-03-26 02:41:44“ date: ungültiges Datum „2008-03-30 02:08:09“ date: ungültiges Datum „2009-03-29 02:09:26“ date: ungültiges Datum „2007-03-25 02:03:47“ For me, this seems to be a bug in the date reading part. The critical combination seems to be end of March and '02' as hour. My setup: uname -a Linux 2.6.31.8-0.1-desktop #1 SMP PREEMPT 2009-12-15 23:55:40 +0100 x86_64 x86_64 x86_64 GNU/Linux --- (LANG=C gives the same errore) echo $LANG de_DE.UTF-8 --- date --version date (GNU coreutils) 7.1 Copyright © 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. No need for an direkt answer, this is not critical for me. best regards Klaus Bramstedt __ Dr. Klaus Bramstedt Tel. +49/421/218-62084 ^^^ Institute of Environmental Physics (IUP)/ Fax +49/421/218-4555 Institute of Remote Sensing (ife) University of Bremen, NW1 Otto-Hahn-Allee 1 D-28359 Bremen, Germany E-mail: klaus.bramst...@iup.physik.uni-bremen.de WWW: http://www.iup.uni-bremen.de __
Re: BUG: date 7.1 - reading date string
Am 04.02.2010 um 14:45 schrieb Klaus Bramstedt: I used the command date -d $DATE for almost all dates between Aug 2002 end Jan 2010 in a script. Date has a format like this 2003-03-30 02:08:17 However, 7 of 42048 randomly distributed dates in the list failed: date: ungültiges Datum „2003-03-30 02:08:17“ date: ungültiges Datum „2003-03-30 02:25:58“ date: ungültiges Datum „2005-03-27 02:08:41“ date: ungültiges Datum „2006-03-26 02:41:44“ date: ungültiges Datum „2008-03-30 02:08:09“ date: ungültiges Datum „2009-03-29 02:09:26“ date: ungültiges Datum „2007-03-25 02:03:47“ For me, this seems to be a bug in the date reading part. The critical combination seems to be end of March and '02' as hour. Yes, it's the non-existent hour during DST adjustment on the last Sunday in March. These dates are indeed invalid in the German timezone. Sven
Re: BUG: date 7.1 - reading date string
On Thu, 4 Feb 2010, Klaus Bramstedt wrote: I used the command date -d $DATE for almost all dates between Aug 2002 end Jan 2010 in a script. Date has a format like this 2003-03-30 02:08:17 However, 7 of 42048 randomly distributed dates in the list failed: date: ungültiges Datum „2003-03-30 02:08:17“ date: ungültiges Datum „2003-03-30 02:25:58“ date: ungültiges Datum „2005-03-27 02:08:41“ date: ungültiges Datum „2006-03-26 02:41:44“ date: ungültiges Datum „2008-03-30 02:08:09“ date: ungültiges Datum „2009-03-29 02:09:26“ date: ungültiges Datum „2007-03-25 02:03:47“ For me, this seems to be a bug in the date reading part. The critical combination seems to be end of March and '02' as hour. You don't say which timezone you're using, but I'll guess Europe/Berlin, in which case this is a DST issue, but not a bug. $ zdump -v Europe/Berlin | grep 2003 Europe/Berlin Sun Mar 30 00:59:59 2003 UTC = Sun Mar 30 01:59:59 2003 CET isdst=0 gmtoff=3600 Europe/Berlin Sun Mar 30 01:00:00 2003 UTC = Sun Mar 30 03:00:00 2003 CEST isdst=1 gmtoff=7200 Europe/Berlin Sun Oct 26 00:59:59 2003 UTC = Sun Oct 26 02:59:59 2003 CEST isdst=1 gmtoff=7200 Europe/Berlin Sun Oct 26 01:00:00 2003 UTC = Sun Oct 26 02:00:00 2003 CET isdst=0 gmtoff=3600 According to the daylight saving rules there was a discontinuity from 01:59:59 - 03:00:00 on the dates you gave above, at the start of DST. Please see this entry in the coreutils FAQ: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e Cheers, Phil
Re: BUG: date 7.1 - reading date string
Klaus Bramstedt wrote: I used the command date -d $DATE for almost all dates between Aug 2002 end Jan 2010 in a script. Date has a format like this 2003-03-30 02:08:17 However, 7 of 42048 randomly distributed dates in the list failed: date: ungültiges Datum „2003-03-30 02:08:17“ date: ungültiges Datum „2003-03-30 02:25:58“ date: ungültiges Datum „2005-03-27 02:08:41“ date: ungültiges Datum „2006-03-26 02:41:44“ date: ungültiges Datum „2008-03-30 02:08:09“ date: ungültiges Datum „2009-03-29 02:09:26“ date: ungültiges Datum „2007-03-25 02:03:47“ For me, this seems to be a bug in the date reading part. The critical combination seems to be end of March and '02' as hour. Those timestamps do not exist because your local daylight savings time skipped over that hour. Those times never existed in your timezone. You didn't say what timezone you were using but for discussion I will assume one. $ zdump -v Europe/Berlin | grep 2009 Europe/Berlin Sun Mar 29 00:59:59 2009 UTC = Sun Mar 29 01:59:59 2009 CET isdst=0 gmtoff=3600 Europe/Berlin Sun Mar 29 01:00:00 2009 UTC = Sun Mar 29 03:00:00 2009 CEST isdst=1 gmtoff=7200 As you can see there was no 2 hour then. It skipped from 01:59:59 to 03:00:00. Please see this reference for more information: http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e Bob
After 'cat' command on binary files : BUG on display
Hello, Please excuse my bad english : Bug Report -- Context: Debian Lenny linux 2.6.26-2-686 XFCE4 with Terminal 0.2.8 coreutils 6.10-6 What I did: --- I tried to display binary files with 'cat': $ cat ~/an_audio_file.rm $ cat /bin/cp What I expected: -- displaying unreadable chars from the binary file; -- and then coming back to the prompt normally! What it actually happened: -- -- displaying unreadable chars from the binary file; -- coming back to the prompt BUT it still displays unreadable chars for the prompt. All characters (after 'cat' command is finished) stay unreadable. (only 'reset' sets the display back) (this last point doesn't happen with XTerm but it does with Terminal and text mode console) -- just after 'cat' command, signifiant characters are already typed in my prompt, as if i typed them with myself. Some examples : DX 62;9;␌ 1;2c1;2c1;2c (this last point happens with XTerm, Terminal, and text mode console) Where I found the bug - - on Terminal 0.2.8 with XFCE - on the text mode console - on XTerm(235) Remark -- Could you please reply to me shortly, just to know whether this report was useful or not? Thanks
Re: After 'cat' command on binary files : BUG on display
david johann wrote: I tried to display binary files with 'cat': $ cat ~/an_audio_file.rm $ cat /bin/cp That isn't expected to behave nicely. You really shouldn't be doing that. What I expected: -- displaying unreadable chars from the binary file; -- and then coming back to the prompt normally! Unfortunately for you your expectations were incorrect. The 'cat' program is not a file viewer program. Although it is often used to throw file contents to the terminal that is only done with the full knowledge that it is a hack and isn't a perfectly correct usage of it. The purpose of the 'cat' program is to concatenate files to the standard output. In this case stdout is your terminal. But your terminal is confused by the data you have sent to it. Binary files contain random data. Your terminal interprets escape sequences. That random data happens to put your terminal into a confused state. That is not a failure of the 'cat' program nor is it a failure of your terminal. It is a user error. Instead use a file browser program such as 'more', 'less', or 'most'. Could you please reply to me shortly, just to know whether this report was useful or not? Perhaps the information gained from it is useful to others who search for similar problems. Bob
Re: After 'cat' command on binary files : BUG on display
Thank you very much! 2010/2/4 Bob Proulx b...@proulx.com david johann wrote: I tried to display binary files with 'cat': $ cat ~/an_audio_file.rm $ cat /bin/cp That isn't expected to behave nicely. You really shouldn't be doing that. What I expected: -- displaying unreadable chars from the binary file; -- and then coming back to the prompt normally! Unfortunately for you your expectations were incorrect. The 'cat' program is not a file viewer program. Although it is often used to throw file contents to the terminal that is only done with the full knowledge that it is a hack and isn't a perfectly correct usage of it. The purpose of the 'cat' program is to concatenate files to the standard output. In this case stdout is your terminal. But your terminal is confused by the data you have sent to it. Binary files contain random data. Your terminal interprets escape sequences. That random data happens to put your terminal into a confused state. That is not a failure of the 'cat' program nor is it a failure of your terminal. It is a user error. Instead use a file browser program such as 'more', 'less', or 'most'. Could you please reply to me shortly, just to know whether this report was useful or not? Perhaps the information gained from it is useful to others who search for similar problems. Bob
