On Sat May 18 08:50:21 2024 Philip Guenther wrote:
> > So yeah, what's needed is pathconfat(2)** but whether this winding loose
> > end ("That poor yak.") merits that much code and surface is yet to be
> > examined deeply.
>
> The fix for this has now been committed, so it'll be in 7.6 and a near
On Thu, May 16, 2024 at 12:08 AM Philip Guenther wrote:
> On Wed, May 15, 2024 at 1:14 AM Philip Guenther wrote:
...
>> I think you've managed to hit a spot where the POSIX standard doesn't
>> provide a way for a program to find the information it needs to do its job
>> correctly. I've filed a
On Fri May 17 09:50:58 2024 Philip Guenther wrote:
> Sounds like you copied with something like 'cp -p' so the copy has a
> mtime with zero nsecs part, so now they do compare as equal.
This morning I realized that when I copied the symlink from the ext2
drive to my hard disk, cp(1) didn't copy the
On Thu, May 16, 2024 at 5:33 AM Walter Alejandro Iglesias
wrote:
>
> On Thu May 16 09:48:45 2024 Philip Guenther wrote:
> > So yeah, what's needed is pathconfat(2)** but whether this winding loose
> > end ("That poor yak.") merits that much code and surface is yet to be
> > examined deeply.
...
>
On Thu May 16 09:48:45 2024 Philip Guenther wrote:
> So yeah, what's needed is pathconfat(2)** but whether this winding loose
> end ("That poor yak.") merits that much code and surface is yet to be
> examined deeply.
>
> Philip Guenther
>
>
> ** or lpathconf(2), but pathconfat(2) is better
>
I rea
On Wed, May 15, 2024 at 1:14 AM Philip Guenther wrote:
> On Tue, May 14, 2024 at 11:59 AM Walter Alejandro Iglesias <
> w...@roquesor.com> wrote:
>
>> Hi Philip,
>>
>> On Tue May 14 19:40:04 2024 Philip Guenther wrote:
>> > If you like, you could try the following patch to pax to more gracefully
On Wed May 15 13:04:53 2024 Walter Alejandro Iglesias wrote:
> After more testing I realized that I was wrong my modification doesn't
> solve the problem.
>
Yeah, I also realized that what I did was stupid. :-)
On Wed May 15 10:24:32 2024 Walter Alejandro Iglesias wrote:
> I get it working but I don't know if what I did is fine.
>
> As I'd told you the problem was ctime (when using -Y), so I added one
> conditional to your diff where it checks only mtime and it works:
>
>
> Index: ar_subs.c
>
On Wed May 15 10:20:04 2024 Philip Guenther wrote:
> I think you've managed to hit a spot where the POSIX standard doesn't
> provide a way for a program to find the information it needs to do its job
> correctly. I've filed a ticket there
>https://austingroupbugs.net/view.php?id=1831
>
> We'll
On Tue, May 14, 2024 at 11:59 AM Walter Alejandro Iglesias
wrote:
> Hi Philip,
>
> On Tue May 14 19:40:04 2024 Philip Guenther wrote:
> > If you like, you could try the following patch to pax to more gracefully
> > handle filesystems with time resolution more granular than nanoseconds.
>
> After
Hi Philip,
On Tue May 14 19:40:04 2024 Philip Guenther wrote:
> If you like, you could try the following patch to pax to more gracefully
> handle filesystems with time resolution more granular than nanoseconds.
After applying your patch, as I'd done before reporting the issue, I
sycronized my hom
If you like, you could try the following patch to pax to more gracefully
handle filesystems with time resolution more granular than nanoseconds.
The whitespace will presumably be mauled by gmail so use patch's -l option.
Philip Guenther
Index: ar_subs.c
==
Removing the inode check (-Y option) files are updated correctly to ext2fs.
So the command would be:
$ pax -rw -v -Z $files $target
So, it's something with the inode check what doesn't work with ext2fs.
On Thu, 2 May 2024 12:03:10, Stuart Henderson wrote
> I don't have a suitable filesystem handy to test, but does OpenBSD's
> implementation of ext2fs support sub-second timestamps?
>
> stat -f %Fm $filename
>
> If not, that's a probable explanation for the difference in behaviour.
> You could proba
On 2024-05-02, Walter Alejandro Iglesias wrote:
> I expect from that command no more and no less than what is explained in
> the man page:
>
> Update (and list) only those files in the destination directory
> /backup which are older (less recent inode change or file
> modification time
I expect from that command no more and no less than what is explained in
the man page:
Update (and list) only those files in the destination directory
/backup which are older (less recent inode change or file
modification times) than files with the same name found in the source
fil
On Tue, Apr 30, 2024 at 5:50 AM Walter Alejandro Iglesias
wrote:
> I'd never used pax(1), reading the man page I found this command can be
> used to make a backup:
>
> $ pax -r -w -v -Y -Z home /backup
>
> Faster than using rsync indeed, but it seems that the -Y and -Z options
> don't work with
17 matches
Mail list logo
