svn commit: r272372 - stable/10/bin/rm

Garrett Cooper yaneurabeya at gmail.com
Sat Oct 4 03:11:10 UTC 2014


On Oct 2, 2014, at 16:34, Bruce Evans <brde at optusnet.com.au> wrote:

> There is still the larger problem with fts_read().  Applications like rm
> are specified to do a complete tree walk, with special handling for files
> that do not exist.  If fts_read() is going to abort in the middle of a
> tree walk, then it is unusable for implementing applications like rm.

+1. In this case I was doing a du -sh /* while I was running rm -Rf /rel (an old make release directory tree). This stopped the du -sh:

$ sudo du -sh /*                                                                                                                                                                
8.0K    /COPYRIGHT
996K    /bin
218M    /boot
  0B    /boot.config
2.5K    /dev
4.0K    /entropy
2.2M    /etc
1.0G    /home
 16M    /lib
280K    /libexec
4.0K    /media
4.0K    /mnt
4.0K    /proc
du: /rel/usr/ports/net/samba36: No such file or directory
du: /rel/usr/ports/net/aslookup: No such file or directory
du: /rel/usr/ports/net/p5-Net-Amazon-AWSSign: No such file or directory
du: /rel/usr/ports/net/p5-Net-Server-SS-PreFork: No such file or directory
du: /rel/usr/ports/net/lla: No such file or directory
du: /rel/usr/ports/net/sslh: No such file or directory
du: /rel/usr/ports/net/wmlj: No such file or directory
du: /rel/usr/ports/net/sendsms: No such file or directory
du: /rel/usr/ports/net/uriparser: No such file or directory
du: /rel/usr/ports/net/p5-Data-IPV4-Range-Parse: No such file or directory
du: /rel/usr/ports/net/cagibi: No such file or directory
du: /rel/usr/ports/net/fsplib: No such file or directory
du: fts_read: No such file or directory

	The problem with changing fts_read to ignore ENOENT or other errors will break compatibility with Linux [and other OSes potentially], and is not the correct solution for this issue. I do however think that the errnos to ignore with -f should be...

- EACCES
- ENOENT
- EPERM

	… as filtering out these errors would handle the case that -f should handle according to the manpage:

     -f      Attempt to remove the files without prompting for confirmation,
             regardless of the file's permissions.  If the file does not
             exist, do not display a diagnostic message or modify the exit
             status to reflect an error.  The -f option overrides any previous
             -i options.

Thanks,
-Garrett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20141003/206528eb/attachment.sig>


More information about the svn-src-all mailing list