bug#6906: [PATCH] cp: copy entirely-sparse files oodles faster
Assaf Gordon wrote: Can this be closed as out-dated? Yes, that's fine. Closing.
bug#6816: df bug on 64-bit Solaris (need to use getextmntent)
Hi Assaf, > In 2014 gnulib gained the following commit: > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=502809019bd2ca3ce3d041d18c35ce9420eedb72 > === > commit 502809019bd2ca3ce3d041d18c35ce9420eedb72 > Author: Ben Walton > Date: Tue Jun 3 23:01:14 2014 +0100 > > mountlist: avoid hasmntopt const type warning on solaris > === > > Which seems to address a similar issue as this bug ( > https://bugs.gnu.org/6816 ). I don't think it's the same bug. Gnulib still does not use getextmntent. > I think recent coreutils build well on 64bit solaris. According to the cited man page, the effect of not using getextmntent is visible at run-time, not at compile-time. > If there are no objections I will close this bug in couple of days. Objection. Bruno
bug#7313: sha1sum etc, output in base64
close 7313 stop (triaging old bugs) Hello, On 02/11/10 11:15 AM, Pádraig Brady wrote: On 02/11/10 16:20, Pádraig Brady wrote: env printf $(sha1sum file | sed 's/ .*//; s/\(..\)/\\x\1/g') | base64 openssl dgst -sha1 -binary $file | openssl enc -base64 And also: sha1sum FILE | xxd -r -p | base64 With no further comments in the last 7 years, I'm closing this bug. regards, - assaf
bug#6816: df bug on 64-bit Solaris (need to use getextmntent)
(triaging old bugs) Hello, On 15/09/10 04:18 PM, Eric Blake wrote: On 08/06/2010 01:56 PM, Wood, David wrote: From mnttab(4) on Solaris 10: [...] At this point, me->me_dev contains a wrongly packed (32-bit) device number, which forces the find_mount_point() code path (causing other unpleasantries). The following patch against coreutils v8.5 fixes the problem: Thanks for the report. Yes, this needs to be folded into gnulib, but it also needs an m4 check for getextmntent, and it would be nice to get by with less in-function #ifdefs. In 2014 gnulib gained the following commit: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=502809019bd2ca3ce3d041d18c35ce9420eedb72 === commit 502809019bd2ca3ce3d041d18c35ce9420eedb72 Author: Ben Walton Date: Tue Jun 3 23:01:14 2014 +0100 mountlist: avoid hasmntopt const type warning on solaris === Which seems to address a similar issue as this bug ( https://bugs.gnu.org/6816 ). I think recent coreutils build well on 64bit solaris. If there are no objections I will close this bug in couple of days. regards, - assaf
bug#6667: dd ?bug? while making image of hdd with bad sectors
tags 6667 notabug close 6667 stop Hello, On 19/07/10 08:44 AM, Pádraig Brady wrote: On 19/07/10 10:05, Jakub Muszynski wrote: I have been trying to make a dd copy : dd if=/dev/sdb conv=noerror,sync bs=4096k|pv| dd of=usb320.dd conv=noerror,sync bs=4096k > dd320.LOG but image took all my free diskspace (406GB), and terminated, eventhough my hdd is 320GB dd doesn't read full blocks by default, so one has to be careful when reading from pipes. [...] Does adding "iflag=fullblock" to the second dd fix things? Since you're not specifying a count, just removing the "sync" option from the second dd is equivalent. With no further comments in 8 years, I'm closing this item. regards, - assaf
bug#6048: bug#11443: linux "cp" and ocfs2 reflink/clone/fastcopy/copy on write
(triaging old bugs) On 14/05/12 07:19 AM, Pádraig Brady wrote: On 05/09/2012 03:28 PM, Kai Petzke wrote: there has been work by others about adding support for the OCFS2 "reflink" ioctl() call, which is similiar to the btrfs "clone" call, and creates a copy-on-write copy of the original, thus allowing to "copy" even gigabyte sized files within a tiny fraction of a second, and without using much additional file system space. See: [...] even though the interface to use to different system calls to achieve the same thing is awkward. But, as laid out in the comments in the source, btrfs clone and ocfs2 reflink are semantically quite different, so that unifying them into one on the kernel side is not likely to happen, soon, if it happens at all. That would be unfortunate. Hopefully a generic reflink() call can be sorted out. In 2014 we had this commit: https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b47231be6813e6cb5305266e391b4bb745f27f13 commit b47231be6813e6cb5305266e391b4bb745f27f13 Author: David Sterba Date: Wed Sep 24 11:15:05 2014 +0100 mv: use reflink=auto mode by default On some filesystems (BTRFS), moving a file within the filesystem may cross subvolume boundaries and we can use a lightweight reflink copy, similar to what cp(1) can do, which is faster than a full file copy. Does this 'reflink=auto' mode addresses OCFS2 as well? I believe so, but want to double-check. If there are no objections, I'll mark this as "fixed/done" in couple of days. regards, - assaf
bug#5918: [dd] conv=sparse option
tags 5918 fixed close 5918 stop Hello, Coreutils version 8.16 (released 2012) gained "dd conv=sparse" option, see https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4e776faa8482ae630d2ea9bc767298e664f07ba9 closing this bug. regards, - assaf
bug#6906: [PATCH] cp: copy entirely-sparse files oodles faster
(triaging old bugs) Hello, On 17/04/11 10:28 AM, Paul Eggert wrote: On 04/17/11 01:55, Jim Meyering wrote: Now that we have FIEMAP support, (by the looks of things we will soon have SEEK_HOLE support in cp and in the linux kernel) do you think adding support for this special case is worthwhile? I could go either way. If so, would you care to rebase it for 8.13? Yes, I expect it's worthwhile, as the FIEMAP stuff isn't universal. I'll add it to my list of thing to do. It's not high priority, to be sure. In the 8 years since the original thread, cp(1) can now copy sparse files very fast (though I suspect it's still with FIEMAP and not SEEK_DATA/HOLE). https://bugs.gnu.org/6906 Can this be closed as out-dated? regards, - assaf
bug#15926: RFE: unlink command already uses 'unlink' call; make 'rm' use 'remove' call
close 15926 stop (triaging old bugs) The original topic of using remove(2) call in rm(1) was decided to be undesirable. Starting at around the 33rd message [1] the thread diverges into bugs in "rm -rf ." and similar problems (which are resolved by the 221st message [2]. [1] https://bugs.gnu.org/15926#33 [2] https://bugs.gnu.org/15926#221 I'm therefore closing this item (it is already marked as "not a bug", relating to the original request). We typically write "discussion can continue by replying to this thread", but in this case I think it should not be encouraged. If there are further issues with "rm", please do start a new thread (if it's a bug - to bug-coreutils@gnu.org ; if a feature request - to coreut...@gnu.org ). regards, - assaf
bug#19681: (no subject)
close 19681 stop Pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=8b2bf5295f353016d4f5e6a2317d55b6a8e7fd00 closing.
bug#19375: (no subject)
tags 19375 fixed close 19375 stop pushed at https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=178f8e79dcd1e0b8bbb3b04da664d05eaae56186 closing.
bug#19154: (no subject)
tags 19154 fixed close 19154 stop Pushed in https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=16e2347bd545057b04a97115563e606ad822ec33 closing.
bug#12964: [PATCH] printenv: -n option added -- show names of variables.
On 10/9/18 11:33 PM, Assaf Gordon wrote: > With your patch, using "printenv -n VARNAME" adds > the variable name to the output. e.g.: > > $ printenv HOME > /home/gordon > > $ printenv -n HOME > HOME=/home/gordon > > From a cursory look this seems like a non-standard extension > that is not available in any other 'printenv' implementations. This feature looks like it should be possible to write out the current settings to a file which could later be sourced in: printenv -n VAR > file and in another shell (to get VAR back): . file I'm afraid this is problematic once the value of a variable starts to have funny characters, even a simple blank ' ' already screws things up. For this kind of save/restore, -n would need to do correct shell quoting. Have a nice day, Berny
