by re-ordering when chmod/chown is done, only a list of directories (not
all files) need be kept for fixing mtime.
this also fixes an issue where set-user-id files in a tar may not work. chmod
is done before chown and before the file is written. if ownership changes, or
the file is being written as a normal user, the setuid bit would be cleared.
also fixes ownership of symbolic links. previously a chown() was called,
which would change the ownership of the link target. lchown() is now
used for symbolic links.
renamed all ent, ent* functions to dir* as it better describes what they
do.
use timespec/utimensat instead of timeval/utimes to get AT_SYMLINK_NOFOLLOW
This reverts commit a564a67c4ea70e90a4dc543814458e4903869d3e.
Not as trivial as I thought. This breaks cp when used as:
cp -r /foo/bar /baz
The old code expands this to:
cp -r /foo/bar /baz/bar
This can happen if you move a file from one filesystem to another.
rename(2) will fail and we will fall through to a manual cp + rm.
Initiate the rm through recurse() like we do for rm(1).
Thanks to Heiko for reporting this.
POSIX says
Copying shall begin at the point in the file indicated by the -c
number or -n number options.
The origin for counting shall be 1; that is, -c +1 represents the
first byte of the file, -c -1 the last.
The origin for counting shall be 1; that is, -n +1 represents the
first line of the file, -n -1 the last.
ls was using (old) UNIX spec (struct stat).st_[acm]time.
It now uses POSIX (struct stat).(struct timespec st_[acm]tim) which
gives time resolution in seconds and nanoseconds.
If two files have the same time in seconds, we extend the comparision to
nanoseconds.
Entities arrays in main() were arrays of pointer to entities and were
not compatible with entcmp().
They have been changed to being arrays of entities.
Thanks to Michael Forney <mforney@mforney.org> for having seen that.
Previously, entcmp was being passed struct entry **, when it expected
struct entry *.
Many autoconf-generated configure scripts use `ls -t` to determine whether or
not the system clock is behaving correctly. If they are sorted in the wrong
order, it produces an error.
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock
After setting up qemu and testing od(1) in a Big Endian environment,
I found out that the conditional in the printing function was not
right.
Instead, it's supposed to be way simpler. While at it, we don't need
HOST_BIG_ENDIAN any more. Just set big_endian properly in main()
and be done with it.
The -e and -E flags allow the user to override the host endianness
and force od(1) to handle input according to a little (-e) or big (-E)
endian environment.
The previous handling was broken as bitshifts alone are already
endian-independent.
Looking at the old code, it became clear that the desired
functionality with the t-flag could not be added unless the
underlying data-structures were reworked.
Thus the only way to be successful was to rewrite the whole thing.
od(1) allows giving arbitrarily many type-specs per call, both via
-t x1o2... and -t x1 -t o2 and intermixed.
This fortunately is easy to parse.
Now, to be flexible, it should not only support types of integral
length. Erroring out like this is inacceptable:
$ echo -n "shrek"| od -t u3
od: invalid type string ‘u3’;
this system doesn't provide a 3-byte integral type
Thus, this new od(1) just collects the bytes until shortly before
printing, when the numbers are written into a long long with the
proper offset.
The bytes per line are just the lcm of all given type-lengths and >= 16.
They are equal to 16 for all types that are possible to print using
the old od(1)'s.
Endianness is of course also supported, needs some testing though,
especially on Big Endian systems.
The one specified by mdoc is hard to read for non-native
speakers from countries which read the date day-first (like
Germany, Greece, North-Korea, Swamp,...).
This is also consistent with how we generally specify dates
at suckless.org.
Rely on what the system provides. These are not standardized macros
but any relevant UNIX system will provide them.
We can revisit this in the future if something breaks.
