Re: [PATCH] tests: copy.c destination permissions lost when backup specified
Sami Kerola wrote: Either this is bug or an unintuitive feature. s...@lelux ~/foo touch src dest s...@lelux ~/foo chmod g-rwx src s...@lelux ~/foo chmod g+rwx dest s...@lelux ~/foo ls -l total 0 -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest -rwr-- 1 sake sake 0 2009-03-30 13:16 src s...@lelux ~/foo cp --force --backup=t src dest s...@lelux ~/foo ls -l total 0 -rwr-- 1 sake sake 0 2009-03-30 13:16 dest -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest.~1~ -rwr-- 1 sake sake 0 2009-03-30 13:16 src In case this is bug the patch is good. In case of feature it should be modified to make sure that permissions are different. It's a feature. With --backup, an existing destination is first moved aside (renamed), and thus the backup retains all attributes. That's the idea of making a backup, after all: preserve as much initial state as possible. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Bug in 'date'
Hi! I'am find a some strange bug in a 'date' program:) Look at this: [...@localhost Shell]$ date +%Y-%m-%d 2009-03-30 [...@localhost Shell]$ date -d 0 day -1 month +%Y-%m-%d 2009-03-02 but must be 2009-02-30 O_o Thanks for attention. P.S. Sorry for my english :) -- BuG Sergey Trubnikov ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Heiko Schlichting on 3/30/2009 3:29 AM: Hi, I read FAQ 24 (The date command is not working right) but the following problem is not what I expect on the day after daylight saving time starts. All the outputs are done at epoch 1238364060, timezone Europe/Berlin using coreutils 7.1. This is one minute after midnight on the day after day light saving starts. Problem! This is 24 hours subtracted but not what is expected as yesterday at the same time of the day. You diagnosed things perfectly - 'yesterday' subtracts 24 hours, even when the previous day was a 23-hour day due to daylight savings. This behavior is documented, and there is no choice we can make that will fit everyone's needs (similar things happen if you subtract or add a 30-day 'month' but in the context of a 28-day or 31-day calendar segment). Both choices (figure out whether the adjustment falls over a special-case boundary, to affect only one calendar unit, vs. always treat a relative date as a fixed length of time without regards to special cases) have their users, and at this point, existing scripts depend on the existing choice. So all we can suggest is to avoid special times (compute 'yesterday' relative to noon, not one minute after midnight; compute 'last month' relative to the 15th, not the first). If you have a suggestion on how to improve the FAQ, we are all ears. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknQtKYACgkQ84KuGfSFAYAWeACdFjkT4DwCTBCGU5Ff1PROoVhc gdYAn2mBcgdyNz2YBbgsuoy7AVXJMeCQ =w/WE -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Bug in 'date'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Sergey Trubnikov on 3/30/2009 5:54 AM: Hi! I'am find a some strange bug in a 'date' program:) Look at this: [...@localhost Shell]$ date +%Y-%m-%d 2009-03-30 [...@localhost Shell]$ date -d 0 day -1 month +%Y-%m-%d 2009-03-02 but must be 2009-02-30 O_o Before you complain, think about it - there is no February 30th. Not a bug - you are moving by a 30-day 'month' but in the context of a 28-day or 31-day calendar segment. This behavior is documented, and there is no choice we can make that will fit everyone's needs (similar things happen 'yesterday' subtracts 24 hours, even when the previous day was a 23-hour day due to daylight savings). Both choices (figure out whether the adjustment falls over a special-case boundary, to affect only one calendar unit, vs. always treat a relative date as a fixed length of time without regards to special cases) have their users, and at this point, existing scripts depend on the existing choice. So all we can suggest is to avoid special times (compute 'yesterday' relative to noon, not one minute after midnight; compute 'last month' relative to the 15th, not the first). If you have a suggestion on how to improve the FAQ, we are all ears. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknQtWcACgkQ84KuGfSFAYBFowCglF5kTuU6glOOZGp2TZGj3br2 f+0AnjXLz9KuI006suZx8vX3o62WXY7Q =rTrx -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] tests: copy.c destination permissions lost when backup specified
On Mon, Mar 30, 2009 at 13:43, Jim Meyering j...@meyering.net wrote: Sami Kerola wrote: Either this is bug or an unintuitive feature. s...@lelux ~/foo touch src dest s...@lelux ~/foo chmod g-rwx src s...@lelux ~/foo chmod g+rwx dest s...@lelux ~/foo ls -l total 0 -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest -rwr-- 1 sake sake 0 2009-03-30 13:16 src s...@lelux ~/foo cp --force --backup=t src dest s...@lelux ~/foo ls -l total 0 -rwr-- 1 sake sake 0 2009-03-30 13:16 dest -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest.~1~ -rwr-- 1 sake sake 0 2009-03-30 13:16 src In case this is bug the patch is good. In case of feature it should be modified to make sure that permissions are different. It's a feature. With --backup, an existing destination is first moved aside (renamed), and thus the backup retains all attributes. That's the idea of making a backup, after all: preserve as much initial state as possible. I give great value for backups, but still I would like to see new and old destination files to have same permissions. Of course when --preserve is specified expectation is changed; source permission should appear for the new file. Am I only one thinking this way? -- Sami Kerola http://www.iki.fi/kerolasa/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] tests: copy.c destination permissions lost when backup specified
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 3/30/2009 6:14 AM: I give great value for backups, but still I would like to see new and old destination files to have same permissions. Of course when --preserve is specified expectation is changed; source permission should appear for the new file. Am I only one thinking this way? Perhaps. In any case, this behavior dates back to the invention of the --backup option over 17 years ago. Sorry, but I see no reason to change it. There is no reason to change the semantics of an existing option. However, there has been list discussion of adding an option to cp that will preserve as many attributes as possible (better than what you currently get with 'touch --reference'); perhaps if that new option is ever written, it can be used in concert with --backup to get the semantics you want? - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknQuM8ACgkQ84KuGfSFAYDxqQCfdwVgFkBQ6ZMUuW+9C6lboQPG ZUsAoK0F0g/GJZWG2+6RimG2cKBjHMMv =C8yR -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] tests: copy.c destination permissions lost when backup specified
Sami Kerola wrote: I give great value for backups, but still I would like to see new and old destination files to have same permissions. Of course when --preserve is specified expectation is changed; source permission should appear for the new file. I agree with Jim. Backup file should maintain as much as possible of the src file, independent of the -p option. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] tests: copy.c destination permissions lost when backup specified
Eric Blake wrote: According to Jim Meyering on 3/30/2009 6:14 AM: I give great value for backups, but still I would like to see new and old destination files to have same permissions. Of course when --preserve is specified expectation is changed; source permission should appear for the new file. Am I only one thinking this way? Perhaps. In any case, this behavior dates back to the invention of the --backup option over 17 years ago. Sorry, but I see no reason to change it. There is no reason to change the semantics of an existing option. However, there has been list discussion of adding an option to cp that will preserve as many attributes as possible (better than what you currently get with 'touch --reference'); perhaps if that new option is ever written, it can be used in concert with --backup to get the semantics you want? Good point. Thanks for putting that in context. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[PATCH] tests: copy.c destination permissions lost when backup specified
Hi, Either this is bug or an unintuitive feature. s...@lelux ~/foo touch src dest s...@lelux ~/foo chmod g-rwx src s...@lelux ~/foo chmod g+rwx dest s...@lelux ~/foo ls -l total 0 -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest -rwr-- 1 sake sake 0 2009-03-30 13:16 src s...@lelux ~/foo cp --force --backup=t src dest s...@lelux ~/foo ls -l total 0 -rwr-- 1 sake sake 0 2009-03-30 13:16 dest -rw-rwxr-- 1 sake sake 0 2009-03-30 13:16 dest.~1~ -rwr-- 1 sake sake 0 2009-03-30 13:16 src In case this is bug the patch is good. In case of feature it should be modified to make sure that permissions are different. -- Sami Kerola http://www.iki.fi/kerolasa/ From 2c4e6f75ced048ec24c13ec8862bc6ae0a6ddb4d Mon Sep 17 00:00:00 2001 From: Sami Kerola kerol...@iki.fi Date: Mon, 30 Mar 2009 13:11:26 +0200 Subject: [PATCH] check that dest and backup permissions are same Cc: kerol...@iki.fi --- tests/cp/backup-dst-perm | 51 ++ 1 files changed, 51 insertions(+), 0 deletions(-) create mode 100644 tests/cp/backup-dst-perm diff --git a/tests/cp/backup-dst-perm b/tests/cp/backup-dst-perm new file mode 100644 index 000..4d6b12c --- /dev/null +++ b/tests/cp/backup-dst-perm @@ -0,0 +1,51 @@ +#!/bin/sh +# +# Test cp destination permissions are not changed when --backup specified +# and source permissions are not asked to be preserved (-p). +# +# Copyright (C) 1997, 1999, 2002, 2004, 2006-2008 Free Software Foundation, Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. + +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +if test $VERBOSE = yes; then + set -x + cp --version +fi + +. $srcdir/test-lib.sh + +file_src=bdpa +file_dst=bdpb +temp_files=$file_src $file_dst +rm -f $temp_files + +fail=0 +touch $temp_files || fail=1 +chmod g-rwx $file_src +chmod g+rwx $file_dst + +# Specify both version control and suffix so the environment variables +# (possibly set by the user running these tests) aren't used. +cp --force --backup=t $file_src $file_dst || fail=1 + +test -f $file_src || fail=1 +test -f $file_dst || fail=1 +test -f $file_dst.~1~ || fail=1 + +dst_mode=`ls -ld $file_dst|cut -b-10` +backup_mode=`ls -ld $file_dst.~1~|cut -b-10` + +test $backup_mode = $dst_mode || fail=1 + +Exit $fail -- 1.6.0.6 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
date problem
Hi, I read FAQ 24 (The date command is not working right) but the following problem is not what I expect on the day after daylight saving time starts. All the outputs are done at epoch 1238364060, timezone Europe/Berlin using coreutils 7.1. This is one minute after midnight on the day after day light saving starts. $ date -d now +%Y%m%d 20090330 $ date -d yesterday +%Y%m%d 20090328 Problem! I expect this to be 20090329. More details: $ date -d now Mon Mar 30 00:01:00 CEST 2009 $ date -d yesterday Sat Mar 28 23:01:00 CET 2009 Problem! This is 24 hours subtracted but not what is expected as yesterday at the same time of the day. Effect: Logfile rotation failed or overwrite logfiles of the day before as date -d yesterday +%Y%m%d outputs the wrong (unexpected) date. Heiko Heiko Schlichting Freie Universität Berlin he...@cis.fu-berlin.de Zentraleinrichtung für Datenverarbeitung (ZEDAT) Telefon +49 30 838-54327 Fabeckstraße 32 Telefax +49 30 838454327 14195 Berlin ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: date problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding the list anyway] According to Heiko Schlichting on 3/30/2009 7:09 AM: Eric, thank you for your quick response. I dont't send this answer to the list as this is a frequent question and bothering people is not my intention. But the question is frequent as this a really unexpected behavior. You can document it and improve the FAQ (which does not really describe this case even after reading FAQ 24 multiple times) but as it is so unexpected, I doubt that this question will cease. If our FAQ doesn't answer the frequent question, then we should improve it. Hence, involving the list is the right thing, when you are arguing that the FAQ is insufficient. If you have a suggestion on how to improve the FAQ, we are all ears. My english is to weak but I would like the cases 'yesterday', '3 days ago', and 'last month' documented. It should also be documented how this can be avoided if the format contains only %d, %m, %Y and so on (which I expected as the usual case): -d '12:00 yesterday' -d '12:00 3 days ago' I don't know about a similar single-call workaround for 'last month' as it is not possible to specify '15th of the actual month' without calling date to get the actual month first. My suggestions: I understand that it is really hard to change the behavior of date but implementing it with an additional keyword should be possible. Something like -d 'real yesterday' (- same time on the previous day, if this time does exists twice as during daylight saving end, use the later. If this time does not exists as during daylight saving start use moment after daylight saving is in effect) -d 'real 1 month ago' (- if this day does not exists (e.g. 30th feb) use the last day of the month) 'real' is hard to implement. An easier or additional solution could be -d 'mid yesterday' (- same a '12:00 yesterday') -d 'mid 1 month ago' (15th of actual month subtracted 30 days) and so on for other relative specifications. Ok, not perfect but these are only suggestions as I doubt that documenting the actual behaviour is not enough. Thanks for the suggestions on improving the date parser. By involving the list, maybe someone with enough interest can write a patch along those lines. Thanks for your fast response again, Heiko. Not a problem. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknQyZUACgkQ84KuGfSFAYAkFQCgzBcOBnPkgbHR35rL8I7TD+yC WaQAn3Z2DOLYIQJ/JWfVBsOGIU50FRan =x2sy -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: bug report
On Fri, 27 Mar 2009, Mary wrote: I just downloaded the new beta afor 9.04 and had the following experience. For the benefit of the list, I've been trying to help to identify the source of Ubuntu queries by replying helpfully to address the question as well as asking where bug-coreutils@gnu.org was seen. In this case, Mary wrote: Well, I believe it was in the information about the beta release. Online. I believe there was a line that said you could report bug at this place. I was lost wandering around, I am not sure where I saw it. Sorry. I can't find any Ubuntu help page which mentions bug-coreutils@gnu.org; perhaps some Ubuntu script is inadvertently calling util --help and printing the bug reporting address? Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv: the --reply option is deprecated; use -i or -f instead
hello, i just read the message as in the subject as i tried to archive some web-pages. the problem with dropping this option is that there is no alternative for --reply=no, if you think twice. this option is quite helpful to not overwrite files of different content but of same name, as is often with web-pages. this also can't be solved with -u. please think twice and at least offer an alternative like: -s skip files if already existing many thanks, dennis heuer ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: the --reply option is deprecated; use -i or -f instead
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dennis Heuer on 3/30/2009 11:10 AM: hello, i just read the message as in the subject as i tried to archive some web-pages. the problem with dropping this option is that there is no alternative for --reply=no, if you think twice. this option is quite helpful to not overwrite files of different content but of same name, as is often with web-pages. this also can't be solved with -u. please think twice and at least offer an alternative like: Consider upgrading: coreutils 7.1 added 'mv --no-clober' for exactly this reason. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknQ/zoACgkQ84KuGfSFAYDh3ACgq9EfYykgjNoyV7YmxCcl8iRf WCgAnR+QovTtIRk2C0Exm0pIqm7xbbjI =iH1q -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: the --reply option is deprecated; use -i or -f instead
Hello Dennis, On Monday 30 March 2009 19:10:11 Dennis Heuer wrote: i just read the message as in the subject as i tried to archive some web-pages. the problem with dropping this option is that there is no alternative for --reply=no, if you think twice. this option is quite helpful to not overwrite files of different content but of same name, as is often with web-pages. this also can't be solved with -u. please think twice and at least offer an alternative like: -s skip files if already existing there is an alternative - new cp/mv option --no-clobber (-n). It was introduced in coreutils 7.1. Kamil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 154602] Re: incorrect cp(1) behaviour upon mkdir foo; cp -r foo foo
Jens Ropers wrote: 2009/3/30 jaduncan jaduncan+launchpad@jaduncan.com: This is correct behaviour as per POSIX - it's how it should work! Says who? I'm confident that POSIX does not require cp -r dir dir to create dir/dir ;-) This is something that would be an upstream bug, but they will not want to change this behaviour. Well, have you asked them? I don't like the existing behavior, but this is a rather hairy corner of copy.c already, and considering we're talking about the state left after the user runs a bogus command (which is surprisingly hard to detect _in general_), I'm in no big hurry to fix it. However, if someone sends in a perfect patch, http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING I'll be very interested. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: new snapshot available: coreutils-7.1.86-9f39f
Jim Meyering wrote: One last snapshot before 7.2, just in case... Does this address any of the test failures in [1]? Or are you planning to release anyway? (For the record, I don't remember there being any failures that would keep me from installing 7.2 anyway, but I've seen almost zero follow-up so far...) 1: http://permalink.gmane.org/gmane.comp.gnu.core-utils.bugs/16395 -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Microsoft has become the next IBM; a dinosaur struggling to survive in the age of more able-to-adapt mammals (FLOSS). It remains to be seen if they'll be able to adapt before they go extinct. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Feature Request: List files/directories lexicographically
This seems like it would be a simple feature and while it may overlap with (or be slightly redundant to) the sort command, sorting lexicographically, i.e., foo1, foo2, foo10, foo20 instead of foo1, foo10, foo2, foo20, would be a nice feature to have. --adam ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [Bug 154602] Re: incorrect cp(1) behaviour upon mkdir foo; cp -r foo foo
Jim Meyering j...@meyering.net writes: I'm confident that POSIX does not require cp -r dir dir to create dir/dir ;-) That's certainly true: an implementation is clearly allowed to (but not required to) report an error and exit without doing anything when it sees this example. However, that's not what GNU cp does, which raises the issue. As near as I can figure out, this is a hole in POSIX. It nowhere specifies what cp should do when inputs and outputs overlap, which they can in even-more-interesting ways than cp -R dir dir. Perhaps this should be raised with the POSIX folks, but in the meantime I don't see that GNU cp needs to change as far as conformance goes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
