Re: rm -r --one-file-system won't delete recursively

[Pádraig Brady]

On 17/12/09 09:50, Jan Larres wrote:

Hi,

trying to delete a directory structure with -r --one-file-system doesn't
work, since it complains about subdirectories being on a different
device, which isn't true.

Simple example:

$ mkdir -p foo/bar
$ rm -r --one-file-system foo
rm: skipping `foo/bar', since it's on a different device
$ rm -r --one-file-system foo/bar/
$ rm -r --one-file-system foo/

Leaving out --one-file-system works as expected.

This is with coreutils 8.1 on Debian unstable.


Oops. This should fix it and will be in the soon to be released 8.3
I'll add a test and commit today after doing a few more checks.

diff --git a/src/remove.c b/src/remove.c
index 5847200..1306e8f 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -548,7 +548,7 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
 if (ent->fts_info == FTS_DP
 && x->one_file_system
 && FTS_ROOTLEVEL < ent->fts_level
-&& ent->fts_statp->st_ino != fts->fts_dev)
+&& ent->fts_statp->st_dev != fts->fts_dev)
   {
 mark_ancestor_dirs (ent);
 error (0, 0, _("skipping %s, since it's on a different device"),

Re: Speed parameter for 'dd' command

[sdrb]

Pádraig Brady pisze:

On 17/12/09 12:20, sdrb wrote:

Hello,

I'd like to ask if it would be possible to add new parameter to "dd"
command. I was thinking about "speed" parameter. Sometimes it is needed
to use "dd" with very large amount of data and the whole process can
cause quite high load average for long time.
Maybe it would be good idea to add some kind of limitation for "dd"
command - and limits I/O operations to given kB or MB per seconds?
For example:

dd if=/dev/zero of=/dev/sda speed=4096k

and it will limits I/O operations to 4MB/s?

Of course the whole "dd" process will take more time to complete in this
case, but at the same time it will be possible to keep load average in
more acceptable values and thus make using system more comfortable.

What do you think?


Well you would only slow things down so as to not take resources
from other processes, but they in turn might not be constantly
using those resources. I.E. it would be better to tell the
system the priorities and let it sort it out optimally.

Have you tried ionice?

cheers,
Pádraig.


You mean - have I tried to use ionice with IDLE class?
Yes, I tried ionice with IDLE parameter, but if I have to run more than 
one "dd" simultaneously - even if I use IDLE class - I have not any 
influence on this how the IDLE class will share I/O resources into those 
dd commands.


My intention was to limit the I/O operations to given value - so it 
could be possible to do I/O at this speed or a bit slower but not faster 
that the set value. It doesn't have to keep given average I/O speed for 
the whole time with 1 byte accuracy.


In the simplest version it could be done by sleeping for some time after 
transmitting one block of data for as long as the average I/O data speed 
is equal to set one with "speed" parameter. This "speed" parameter could 
be optional - not obligatory.


I've made some patch for doing this and it works quite good. It allows 
to keep very low load average, but of course the whole "dd" process 
takes much more time to finish.

Re: Speed parameter for 'dd' command

[Pádraig Brady]

On 18/12/09 14:11, sdrb wrote:

You mean - have I tried to use ionice with IDLE class?
Yes, I tried ionice with IDLE parameter, but if I have to run more than
one "dd" simultaneously - even if I use IDLE class - I have not any
influence on this how the IDLE class will share I/O resources into those
dd commands.

My intention was to limit the I/O operations to given value - so it
could be possible to do I/O at this speed or a bit slower but not faster
that the set value. It doesn't have to keep given average I/O speed for
the whole time with 1 byte accuracy.

In the simplest version it could be done by sleeping for some time after
transmitting one block of data for as long as the average I/O data speed
is equal to set one with "speed" parameter. This "speed" parameter could
be optional - not obligatory.

I've made some patch for doing this and it works quite good. It allows
to keep very low load average, but of course the whole "dd" process
takes much more time to finish.


I don't think this belongs in dd.
Have you tried `rsync --bwlimit` or `pv -L` ?

cheers,
Pádraig.

[bug #28341] chown does not support non-root usage

[anonymous]

URL:
  

 Summary: chown does not support non-root usage
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Fri 18 Dec 2009 07:58:38 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Any attempts to change a file from one owner to another fails, even if the
owner is a member of the same group, and the directory is writable.  For
example:

> dir -a
drwxrwsr-x  7 www-data www 4.0K 2009-09-14 14:14 .
drwxrwsr-x 11 www-data www 4.0K 2009-11-05 16:16 ..
-rw-rw-r--  1 www-data www 2.1K 2009-12-18 14:16 file.txt

> chown user file.txt
chown: changing ownership of `file.txt': Operation not permitted

Yet this works just file:

> cp file.txt file.txt.takeown
> rm file.txt
> mv file.txt.takeown
> touch -m -d 2009-12-18 14:16 file.txt
> chown 664 file.txt
> dir
-rw-rw-r--  1 user www 2.1K 2009-12-18 14:16 file.txt

The chown command should detect conditions like this and allow for the user
to take over ownership of a file without the need for unnecessary file access
or adjustment commands.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[bug #28341] chown does not support non-root usage

[Bob Proulx]

Update of bug #28341 (project coreutils):

 Assigned to:None => rwp
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Thanks for the report.  But this is not a bug in chown but is a restriction
of the operating system kernel.

The GNU chown program will change the ownership if the operating system it is
running upon allows it. If you can't change file ownership then it is the
operating system which is restricting you and not the chown program.  And
indeed the error message you reported "Operation not permitted" is the
operating system kernel message saying that the operation is not permitted. 
This is a security restriction and is outside of the control of the chown
program.

There is more information on this topic in the FAQ:

 
http://www.gnu.org/software/coreutils/faq/#Why-can-only-root-chown-files_003f

Since this bug report was submitted anonymously there is no way to send you
information other than in this report.  If you wish further discussion I
suggest sending a message to the bug-coreutils mailing list.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/