bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ACL patch feedback


From: James Youngman
Subject: Re: ACL patch feedback
Date: Thu, 24 Nov 2005 19:18:58 +0000
User-agent: Mutt/1.5.9i

On Thu, Nov 24, 2005 at 02:31:12PM +0100, Jim Meyering wrote:

> Here's some feedback:
Here's some feedback feedback :)  

> [assuming there's a good reason for --attributes=REGEX, ]
> With the XATTR changes, copy.c's copy_extended_attributes
> exits if it encounters an invalid xattr regexp.  It'd be better
> not to do that.  cp and mv should continue processing
> remaining command-line arguments even if there's a failure
> with a preceding one.  

I haven't read the patch, but are you sure about this?  If I want cp
to do something specific and it can't do it or my request was wrongly
formed, I'd prefer it to exit with a nonzero status, and preferably
without having done anything at all.  

The only circumstances where I would want cp (or, pretty much, any
other tool) to continue past a failure would be Where my exact request
could not be fufilled, but where the actual action taken was the
nearest that could sensibly be achieved (i.e. it came as close as was
possible) and no real data loss will occur if I assume complete
success.  

I'm thinking here about the case where I do "cp -a" onto a FAT
filesystem and the file I'm copying has a timestamp containing an odd
number of seconds.  FAT has a timestamp granularity of two seconds,
and so the choices are to accept the precision loss or fail every
time.  Similarly for copying in the other direction (FAT files can
have a timestamp field of 62 seconds, which Unix files can't).

For problems with command-line argument parsing (which is what we were
oginally talking about , right?) I'd prefer cp to fail without doing
anything.  For runtime failures encoutered after processing of files
has started, it's OK to continue doing stuff, as long as the end
result is that the tool informs me that there was a problem:

$ rm -rf a b c dest; touch a c; mkdir dest; cp a b c dest; echo Exit status is 
$?; ls -l dest
cp: cannot stat `b': No such file or directory
Exit status is 1
total 0
-rw-r--r--  1 jay jay 0 2005-11-24 10:52 a
-rw-r--r--  1 jay jay 0 2005-11-24 10:52 c

... so I still like this outcome (i.e. copying 'c') because the exit
status is nonzero.

I'd prefer tools to fail rather than perhaps do something I didn't
quite intend, and particularly so if the difference in behaviour is
subtle.

If there is a divorce between the appropriateness of my comments and
reality, please accept my apology for not having actually read the
patch...

Regards,
James.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]