one more openat-style function required: fchmodat
Please consider adding an fchmodat function, analogous to fchownat. I've rewritten coreutils' fts.c not to change the current working directory. That included adjusting the clients that use fts: du, chmod, chown, chgrp. In the process, I found that neither Solaris nor glibc provides a directory-fd-relative chmod function, which I needed for src/chmod.c. It is straightforward to simulate the function using /proc/self/fd// or save_cwd/fchdir/chmod/restore_cwd, but it'd be better to have a native (and glibc-supported) implementation to go along with all of the other ones. Since Solaris didn't add that interface[*], I'm wondering if I'm missing something. Can it be simulated some other way? Using openat and fchmod is not adequate, because openat fails for inaccessible files. If a file were chmod'd to 0 (or even to u-rw), we'd be unable to adjust permissions without first using chdir. A google search for chmodat found nothing interesting, but there is a single, tantalizing reference to a Solaris function named fchmodat. It's an entry in the _Index for Solaris Systems Programming_: fchmodat function, 597-599 If anyone knows more about that, please share. In case you're wondering how/why chmod -R now needs fchmodat, it's because this new version of fts traverses the hierarchy via a virtual working directory. As a result, the driver chmod.c is no longer fchdir/chdir'd to each directory, but instead gets a file descriptor, FD, open on each. So rather than chmod (file, mode), it now needs to do something like fchmodat (FD, file, mode, 0). -- [*] but Solaris didn't add mkdirat either, so maybe the lack of fchmodat means nothing. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
euidaccessat [Re: one more openat-style function required: fchmodat
Roland McGrath <[EMAIL PROTECTED]> wrote:
> It's a natural, obvious, and useful addition, no matter what Solaris does
> or doesn't have. I've put it in.
Thanks for the speedy addition!
> If there are any more *at additions that
> might be useful, right now is the time to bring them up. So rack your brain.
In case I didn't mention it on this list before, euidaccessat is one
function that is required to implement a POSIX-conforming rm(1) based
on a chdir-free recursive-removal function.
Here is the relevant function from coreutils/src/remove.c.
If you can see a way to do this without a function like euidaccessat,
POSIX-conformance weenies using rm on deep ACL/xattr-protected trees
will thank you. FYI, this function serves only to determine whether
rm (without -f) should prompt the user before removing the file or
directory in question, so it's not a big deal either way.
/* Return true if FILE is determined to be an unwritable non-symlink.
Otherwise, return false (including when lstat'ing it fails).
If lstat (aka fstatat) succeeds, set *BUF_P to BUF.
This is to avoid calling euidaccess when FILE is a symlink. */
static bool
write_protected_non_symlink (int fd_cwd,
char const *file,
Dirstack_state const *ds,
struct stat **buf_p,
struct stat *buf)
{
if (fstatat (fd_cwd, file, buf, AT_SYMLINK_NOFOLLOW) != 0)
return false;
*buf_p = buf;
if (S_ISLNK (buf->st_mode))
return false;
/* Here, we know FILE is not a symbolic link. */
/* In order to be reentrant -- i.e., to avoid changing the working
directory, and at the same time to be able to deal with alternate
access control mechanisms (ACLs, xattr-style attributes) and
arbitrarily deep trees -- we need a function like eaccessat, i.e.,
like Solaris' eaccess, but fd-relative, in the spirit of openat. */
/* In the absence of a native eaccessat function, here are some of
the implementation choices [#4 and #5 were suggested by Paul Eggert]:
1) call openat with O_WRONLY|O_NOCTTY
Disadvantage: may create the file and doesn't work for directory,
may mistakenly report `unwritable' for EROFS or ACLs even though
perm bits say the file is writable.
2) fake eaccessat (save_cwd, fchdir, call euidaccess, restore_cwd)
Disadvantage: changes working directory (not reentrant) and can't
work if save_cwd fails.
3) if (euidaccess (full_filename (file), W_OK) == 0)
Disadvantage: doesn't work if full_filename is too long.
Inefficient for very deep trees (O(Depth^2)).
4) If the full pathname is sufficiently short (say, less than
PATH_MAX or 8192 bytes, whichever is shorter):
use method (3) (i.e., euidaccess (full_filename (file), W_OK));
Otherwise: vfork, fchdir in the child, run euidaccess in the
child, then the child exits with a status that tells the parent
whether euidaccess succeeded.
This avoids the O(N**2) algorithm of method (3), and it also avoids
the failure-due-to-too-long-file-names of method (3), but it's fast
in the normal shallow case. It also avoids the lack-of-reentrancy
and the save_cwd problems.
Disadvantage; it uses a process slot for very-long file names,
and would be very slow for hierarchies with many such files.
5) If the full file name is sufficiently short (say, less than
PATH_MAX or 8192 bytes, whichever is shorter):
use method (3) (i.e., euidaccess (full_filename (file), W_OK));
Otherwise: look just at the file bits. Perhaps issue a warning
the first time this occurs.
This is like (4), except for the "Otherwise" case where it isn't as
"perfect" as (4) but is considerably faster. It conforms to current
POSIX, and is uniformly better than what Solaris and FreeBSD do (they
mess up with long file names). */
{
/* This implements #5: */
size_t file_name_len
= obstack_object_size (&ds->dir_stack) + strlen (file);
return (file_name_len < MIN (PATH_MAX, 8192)
? euidaccess (full_filename (file), W_OK) != 0 && errno == EACCES
: euidaccess_stat (buf, W_OK) != 0);
}
}
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: "sort" utility short comming or bug: cannot sort according to "human format" criterion.
Pádraig Brady wrote:
>Andre Gompel wrote:
>
>
>
>>Dear colleague:
>> it looks like a bug... or at least a short comming.
>>
>>If I use the -n or -g option I cannot sort according to the output format of
>>the "du" or "ls" commands.
>>
>>Example:
>>
>> du -chs * |sort -n |more
>>
>>I am not sure what would be the best approach, but I would tend to add one
>>more option (says -h for "human format" compatibility).
>>
>>
>>
>>
>I see what you mean, but that would definitely not
>be a stable sort as info is lost in the number -> human conversion.
>You really need to sort before the human conversion.
>Have a look at: http://www.pixelbeat.org/scripts/dutop
>
>
Actually thinking a bit more about this, a seperate util for
formating numbers for human consumption would be useful.
I threw the attached python prog together as an example.
for the above example you would use it like:
du -cbs * | sort -k1,1n | ./human.py --columns=1 --divisor=1000
Do others think a util like this would a useful addition to coreutils?
cheers,
Pádraig.
#!/usr/bin/env python
#TODO: support ranges for --column option
#TODO: support converting from back from "human" numbers to "standard" numbers
#TODO: support aligning output like `column -t`
#TODO: support --col-delimiters option
import os
import sys
import getopt
def Usage():
print "Usage: %s [OPTION] [PATH]" % os.path.split(sys.argv[0])[1]
print "--divisor=value The default value is 1 which means insert thousands seperator."
print " Other possible values are 1000 and 1024."
print "--columns=1,2,3"
print "--helpdisplay help"
try:
lOpts, lArgs = getopt.getopt(sys.argv[1:], "", ["help","divisor=","columns="])
if len(lArgs) == 0:
infile = sys.stdin
elif len(lArgs) == 1:
infile = file(lArgs[0])
else:
Usage()
sys.exit(None)
if ("--help","") in lOpts:
Usage()
sys.exit(None)
divisor=1
columns=[]
for opt in lOpts:
if opt[0] == "--divisor":
divisor=opt[1]
if divisor == "1":
divisor = 1
elif divisor=="1000" or divisor=="1024":
divisor = float(divisor)
else:
raise getopt.error, "Invalid divisor"
if opt[0] == "--columns":
columns=[int(col) for col in opt[1].split(",")]
except getopt.error, msg:
print msg
print
Usage()
sys.exit(2)
import locale
locale.setlocale(locale.LC_ALL,'')
def human(num, power=" "):
if divisor == 1:
return locale.format("%.1f",num,1)
powers=[" ","K","M","G","T"]
while num >= 1000:
num /= divisor
power=powers[powers.index(power)+1]
human(num,power)
return "%6.1f%s" % (num,power)
for line in infile:
line = line.split()
column=0
for str in line:
column+=1
if not len(columns) or column in columns:
try:
num = float(str)
str = human(num)
if str.endswith(".0 "):
str = str[:-3]+" "
elif str.endswith(".0"):
str = str[:-2]
except:
pass
print str,
print
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Test Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Alfred M. Szmidt on 1/4/2006 6:18 PM: >I compiled without problem coreutils 5.93, but when I executed >"make check" there was one failed test. The failed test was >close-stdout > > You haven't given any information about the system you compiled GNU > coreutils 5.93 on, so it is hard to figure out what might have gone > wrong. Also, you should run with "make -k check", so that the testsuite can continue beyond the first failure, and give us a picture of whether any other failures exist in later tests that might have a related root cause. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDvR6184KuGfSFAYARArfZAJ9mEf1fvC0WMl66ALZfIQwDKTCd5ACeNOeB rQsborewSVnbOBB/GROB8BQ= =WYOk -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: euidaccessat [Re: one more openat-style function required: fchmodat
Roland McGrath <[EMAIL PROTECTED]> wrote: > Is Solaris eaccess the same as euidaccess? Yes. Irix and FreeBSD have eaccess, too. > Should glibc provide eaccess as > an alias for euidaccess? Good idea. > Except on the Hurd, euidaccess actually either just uses access (when r==e) > or uses stat and the usual st_mode rules assuming those are what the > filesystem will actually use, which you can do yourself. rm et al I expect > are never setuid and so can always use the method of calling access, which I admit it is very unlikely that anyone will ever find a use for an rm binary with the set-UID bit set. However, rm might easily be invoked from a set-UID program or script, and using access(2) in that context would be wrong. > is superior in telling truth about permission, but lacks the *at features. > > In keeping with the other interfaces, it should be faccessat and use a new > AT_* flag bit to distinguish real-user from effective-user access checking. > > int faccessat (int fd, const char *file, int type, int flag); > > Does that sound reasonable? That sounds fine. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Using DD to write to a specific LBA (converting LBA to offset, blocksize, count)
Hard drive sectors are 512 bytes so use a bs of 512 and skip FF68 blocks. I'm not sure if dd will accept hex numbers, try prefixing it with a 0x ( the C convention for hex numbers ). Otherwise, convert the hex number to decimal. Mark Perino wrote: How does one convert from LBA to skip, blocksize, and count? IE I want to write zero's over LBA 00FF68 through 00FF6F on a raw device /dev/sda /dev/rhdisk4, /drv/C0T0D0S1, etc.. As an example under AIX I would like to use: dd if=/dev/zero of=/dev/rhdisk4 skip= blocksize= count= Where can I obtain the info to calculate , and ? Whatever platform you can show me how to do the math on I can probably figure out how to do this on AIX, Linux, Solaris, etc.. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: one more openat-style function required: fchmodat
It's a natural, obvious, and useful addition, no matter what Solaris does or doesn't have. I've put it in. If there are any more *at additions that might be useful, right now is the time to bring them up. So rack your brain. Thanks, Roland ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: euidaccessat [Re: one more openat-style function required: fchmodat
Is Solaris eaccess the same as euidaccess? Should glibc provide eaccess as an alias for euidaccess? Except on the Hurd, euidaccess actually either just uses access (when r==e) or uses stat and the usual st_mode rules assuming those are what the filesystem will actually use, which you can do yourself. rm et al I expect are never setuid and so can always use the method of calling access, which is superior in telling truth about permission, but lacks the *at features. In keeping with the other interfaces, it should be faccessat and use a new AT_* flag bit to distinguish real-user from effective-user access checking. int faccessat (int fd, const char *file, int type, int flag); Does that sound reasonable? Thanks, Roland ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
build failure on sparc64-sun-solaris2.9
Hi, I was attempting to build 64-bit coreutils on Solaris 2.9 system using gcc 4.0.2. I got this compilation error: if gcc -DHAVE_CONFIG_H -DLIBDIR=\"/opt/pbl/lib/sparcv9\" -I. -I../../lib -I.. -I.. -I../../lib -g -O2 -MT canon-host.o -MD -MP -MF ".deps/canon-host.Tpo" -c -o canon-host.o ../../lib/canon-host.c; \ then mv -f ".deps/canon-host.Tpo" ".deps/canon-host.Po"; else rm -f ".deps/canon-host.Tpo"; exit 1; fi In file included from ../../lib/getaddrinfo.h:28, from ../../lib/canon-host.c:27: /usr/include/sys/socket.h:61: error: two or more data types in declaration specifiers Looking at the sys/socket.h, the line 61 reads: typedef uint32_tsocklen_t; Looking at the sys/int_types.h (which is included by sys/socket.h via sys/types.h), the uint32_t seems to be defined correctly: typedef unsigned intuint32_t; (both in system one, and the "fixincludes" one). Hmph... Strange. The uint32_t should be available on Solaris as soon as sys/socet.h is included (wrote short test program to confirm this). Any idea what is going on here? Regards, Alex This message was sent using IMP, the Internet Messaging Program. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: build failure on sparc64-sun-solaris2.9
Aleksandar Milivojevic <[EMAIL PROTECTED]> writes: > if gcc -DHAVE_CONFIG_H -DLIBDIR=\"/opt/pbl/lib/sparcv9\" -I. -I../../lib -I.. > -I.. -I../../lib -g -O2 -MT canon-host.o -MD -MP -MF ".deps/canon-host.Tpo" > -c -o canon-host.o ../../lib/canon-host.c; \ > then mv -f ".deps/canon-host.Tpo" ".deps/canon-host.Po"; else rm -f > ".deps/canon-host.Tpo"; exit 1; fi > In file included from ../../lib/getaddrinfo.h:28, > from ../../lib/canon-host.c:27: > /usr/include/sys/socket.h:61: error: two or more data types in declaration > specifiers Shouldn't you be using "gcc -m64" if you want to build a 64-bit version? (Or perhaps you have a special gcc that defaults to 64-bit?) I tried to reproduce your problem with coreutils 5.93 on a Solaris 9 sparc host with GCC 4.0.2, using "configure CC='gcc -m64'", and didn't have that problem. Perhaps you're using an older coreutils release? If so, please upgrade. > Looking at the sys/socket.h, the line 61 reads: > > typedef uint32_tsocklen_t; Most likely your "configure" went wrong, and put a "#define socklen_t int" into config.h. If so, you should investigate why. But first, upgrade to 5.93. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: build failure on sparc64-sun-solaris2.9
Paul Eggert wrote:
Aleksandar Milivojevic <[EMAIL PROTECTED]> writes:
if gcc -DHAVE_CONFIG_H -DLIBDIR=\"/opt/pbl/lib/sparcv9\" -I. -I../../lib -I..
-I.. -I../../lib -g -O2 -MT canon-host.o -MD -MP -MF ".deps/canon-host.Tpo"
-c -o canon-host.o ../../lib/canon-host.c; \
then mv -f ".deps/canon-host.Tpo" ".deps/canon-host.Po"; else rm -f
".deps/canon-host.Tpo"; exit 1; fi
In file included from ../../lib/getaddrinfo.h:28,
from ../../lib/canon-host.c:27:
/usr/include/sys/socket.h:61: error: two or more data types in declaration
specifiers
Shouldn't you be using "gcc -m64" if you want to build a 64-bit version?
(Or perhaps you have a special gcc that defaults to 64-bit?)
I'm using sparc64 build of gcc, which defaults to 64-bit (it isn't
special, just not common).
I tried to reproduce your problem with coreutils 5.93 on a Solaris 9
sparc host with GCC 4.0.2, using "configure CC='gcc -m64'", and didn't
have that problem.
Using 5.93 too. The problem was due to bug in gcc (blame the compiler ;-)
See explanation bellow.
Most likely your "configure" went wrong, and put a "#define socklen_t
int" into config.h. If so, you should investigate why. But first,
upgrade to 5.93.
Yup, the configure script went wrong, and defined socklen_t in config.h.
Sparc64 gcc when built with NLS support (default) has a problem that it
core dumps from time to time if there are any warnings or errors during
compilation. It's a known bug. The sparc (32bit) build is not affected
(the bug exists in both builds, but is triggered only in sparc64 build
due to different type sizes). The test for socklen_t triggered an
warning to be printed by gcc ("warning: extra tokens at end of #endif
directive"). Gcc crashed, and configure concluded that there's no
socklen_t defined in system header files.
In the meantime, I rebuilt gcc without NLS support (the bug was rather
annoying, and I don't need gcc to tell me how bad my code is in exotic
languages). This time, everything went fine.
BTW, during install, I got this message for each and every file that was
copied:
../../build-aux/install-sh: -: not found
Also, seems like linking of utilities isn't quite optimal. Running ldd
on any of them gives a long list of libs.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
