Hello everyone :) I'd like to follow up on this thread of mine, if that's okay? Is there anything I could do to get the feature functionality of "using rsync to create a thin (attributes-only) copy" upstream on the long term? Could I talk to a developer, for hire? I'm really professionally interested in such a feature, as it would greatly make our lives in the galleries-libraries-archives-museums (GLAM) world :D Thank you very much in advance! Peter B. On 11.12.24 17:17, Peter B. via rsync wrote:> On 12/10/24 21:15, Roland Kletzing wrote: >> hello, >> that sounds interesting - just one question:? what about file size? is >> it always zero or is it set to the original size and the file contents >> are empty ? > > The filesize (IMO) should stay 0 bytes, since the file actually /is/ > empty. > I believe forging the filesize number in the filesystem to its source > (original) size would be more misleading than helpful... > > When working with xattrs, one gets used to 0-Byte files pretty quickly > though :) > > However, I like to store the original filesize as "yet-another" > metadata key/value xattr information with the 0-Byte files. Works like > a charm and so it's clear that "there is no payload" - but it's a > stub, referring to another file. > > > Regards, > Peter > > >
Stein Vidar Hagfors Haugan
2025-Feb-16 13:39 UTC
Create "thincopy": with fileystem metadata only?
Actually... I have made an extremely small and simple patch implementing an option --time-only, and I have made a pull request for it: https://github.com/RsyncProject/rsync/pull/719 It allows you to truncate your local files after transfer. Outside of rsync, you must then truncate the file to zero size, then set the time stamp back to the original time. On the next run, the file will not be retransmitted as it looks only to the file stamp, ignoring the size. The patch does not do the truncation & time preservation, but that can be handled by a postprocessing shell. I use this b/c we need to sync some data that's stored in uncompressed files, but we want them to be stored compressed on our systems. So we create a gzipped version, truncate the original and set the time stamp back to the original. Does that work for you? Of course, it would be even better if one could implement a --truncate option, too (probably easiest to slip it into the existing code post-transfer, right before the time stamp is set to that of the source file). The post-processing is quite simple though: ~> ls -l original-file.txt -rw-r--r--. 1 steinhh astuser 1010880 Jan 3 2017 original-file.txt ~> touch --reference=original-file.txt /tmp/reference ~> truncate -s 0 original-file.txt ~> touch --reference=/tmp/reference original-file.txt ~> ls -l original-file.txt -rw-r--r--. 1 steinhh astuser 0 Jan 3 2017 original-file.txt I'll bake it into another (or the same) patch if you give me a month of time, never mind the money. A month includes overhead & a nice profit, I really need the time ;-). Cheers, hope this will work for you! Stein Haugan> On 15 Feb 2025, at 21:24, Peter B. via rsync <rsync at lists.samba.org> wrote: > > Hello everyone :) > > I'd like to follow up on this thread of mine, if that's okay? > > Is there anything I could do to get the feature functionality of "using rsync to create a thin (attributes-only) copy" upstream on the long term? > > Could I talk to a developer, for hire? > I'm really professionally interested in such a feature, as it would greatly make our lives in the galleries-libraries-archives-museums (GLAM) world :D > > > Thank you very much in advance! > Peter B. > > > On 11.12.24 17:17, Peter B. via rsync wrote: >> On 12/10/24 21:15, Roland Kletzing wrote: >>> hello, >>> that sounds interesting - just one question: what about file size? is >>> it always zero or is it set to the original size and the file contents >>> are empty ? >> >> The filesize (IMO) should stay 0 bytes, since the file actually /is/ empty. >> I believe forging the filesize number in the filesystem to its source (original) size would be more misleading than helpful... >> >> When working with xattrs, one gets used to 0-Byte files pretty quickly though :) >> >> However, I like to store the original filesize as "yet-another" metadata key/value xattr information with the 0-Byte files. Works like a charm and so it's clear that "there is no payload" - but it's a stub, referring to another file. >> >> >> Regards, >> Peter >> >> >> > > > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html