From owner-freebsd-questions@freebsd.org Tue Jan 29 22:00:33 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60FEB14A993E for ; Tue, 29 Jan 2019 22:00:33 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B5AE6D403 for ; Tue, 29 Jan 2019 22:00:32 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([92.193.226.69]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPA (Nemesis) id 1MXGSU-1gfE0S34EY-00YfWw; Tue, 29 Jan 2019 23:00:18 +0100 Date: Tue, 29 Jan 2019 23:00:18 +0100 From: Polytropon To: byrnejb@harte-lyne.ca Cc: freebsd-questions@freebsd.org Subject: Re: RSYNC changes file name Message-Id: <20190129230018.a028f4fd.freebsd@edvax.de> In-Reply-To: References: <9aaa35912b122e88e667e7516ba6a865.squirrel@webmail.harte-lyne.ca> <20190129204033.7312742f.freebsd@edvax.de> <10a14c28507feee71572a2573d319fc3.squirrel@webmail.harte-lyne.ca> <20190129214351.2f32c04c.freebsd@edvax.de> <18bd6c1326e011634c5b548e5cfd94aa.squirrel@webmail.harte-lyne.ca> <20190129222126.d0449659.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:85VvnKvcrmk7josmY8ouebcQkt4juazsmezmHNySnCDMz8+k3n9 UweF0EO3AzVZSQeltyW3q2sBypWic3WSY/DjYkJWZivIbez7R7Zin/gcOZiCXjFqgZ8ZNgl yEXzKruHQ723XFN8T3Zy8Eyfic+5GQYgN4FBieTcXgguOYnQW6uKo7pnmXwh+JKBWrmNYw8 hjVRW/Fk/UH5OQtEX/3UA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:uOg2/AIXwgU=:FZsHXgZv8LX71gq0sxyrsj hnMXSBwwTCtvb/rv2c6xzALseErEqGG/HvzbNsY29Cyon1cZpUjvvf6UZfSm/w8sFEf78EUe8 tFPKnsmfnhThyo3Nb8QKqm3MV5aljzXW9uJFJ7Iw0mfhkpWp0H2d4TNR2Lsv6sP1dA0+dwV/5 l8tV71bQwv7scINLJWxXkEqc10pE6YkKwODwCPgoNeeSVp+cUEne1upHIPhxgU/5rvW+bZBwT PgAA4m7A7uuAxEdEszE96eiaPV/2AOOkLZg7eEZnRS2vS0Et4N1KZz3cB+hJpUNHfwCVSsgzk tYos1Va1Q7QDMZMLC6zNZL8rtcXgOfdfpNTfll7+w/dO2Lt1bDHFi2vQx6TRtHjSWUFATmc8k 6aI0jyV+LTeBbfMKjR4pBaCKxZl7JPKSAKx4al74x00LdlhG5pAE76Nfnz1sQjhZG4Ank+Zjt PwioVlN9JclqXglT2WMNZszHavvasxubI8EjYwb0ynRQ8VoD12EXzlhFeUQVstjnh9QScBQl5 sTH0/VluVrmpn06kVcQieJDi5JyBiIYfJ7ds+7dUnSA+lRuIQyOQ1Y5/lcOUHoag73kquyfqQ vfobjbU+c6yd8eqyhL+IA26QBpNhN28jWiQTPGdeHWtCsbSD6IGP6PgXJ/YRSgn3IqoP6z68t eFppplrXNbcG8HkZE5JtpYQACjh2wJzLgDJl2wazASuYr+j8GD3xJ3i0/fpbBTzKbXBRkgWaj DU2XYTclhTjUi3pP2d3zl+yTCl9C7IXseqZFU6vt1Kzt1wn9moFqxa8UytY= X-Rspamd-Queue-Id: 4B5AE6D403 X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [6.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; MX_GOOD(-0.01)[cached: mx01.schlund.de]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[69.226.193.92.zen.spamhaus.org : 127.0.0.10]; IP_SCORE(0.69)[ip: (2.01), ipnet: 212.227.0.0/16(-0.70), asn: 8560(2.13), country: DE(-0.01)]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.979,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[0.997,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[187.126.227.212.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[] X-Spam: Yes X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 22:00:33 -0000 On Tue, 29 Jan 2019 16:35:29 -0500, James B. Byrne wrote: > On Tue, January 29, 2019 16:21, Polytropon wrote: > > On Tue, 29 Jan 2019 16:13:46 -0500, James B. Byrne wrote: > >> > >> > >> On Tue, January 29, 2019 15:43, Polytropon wrote: > >> > On Tue, 29 Jan 2019 15:28:50 -0500, James B. Byrne wrote: > >> >> Gpart reports the file system is type 12 which I believe is some > >> >> variant of FAT. MS Windows does not permit file names ending in > >> >> either a dot or a space. The filesystem silently truncates the > >> >> offending character. > >> > > >> > Ha, just as I thought. :-) > >> > > >> > If you're going to use the target medium for FreeBSD > >> > only (i. e., you won't access it from "Windows"), why > >> > not initialize it with UFS? There are even tunefs > >> > options that can help optimizing access to specific > >> > media, like USB sticks or SD cards. In fact, there > >> > even isn't a need for a partition table, if you for > >> > example do "newfs /dev/da0" (where da0 corresponds > >> > to the medium in question), and then you can use it > >> > as "mount -t ufs /dev/da0 /mnt" without problems. > >> > Filenames will then correctly be stored. > >> > > >> > Suggestion: For backing up FreeBSD stuff, keep using > >> > FreeBSD stuff. :-) > >> > > >> > >> The resulting archives must be readable on a windows OS. It is a > >> portable backup which may have to be used in situations where any > >> form > >> of *nix will not be available to me. > > > > You say, "the archives", but it seems you're copying > > bare files. A convenient to deal with this problem is > > to "encapsulate" the whole thing in a "| tar" pipe. > > There are versions of the tar program available even > > for "Windows". Inside a tar archive, a file "12345." > > can be stored, while the archive itself can have a > > name that does not violate FAT rules. > > > > Of course, this introduces another problem: Can you > > make sure that the system you'll be using will be > > able to use tar? It's not for the compression (which > > you _could_ use), just for the "encapsulation". > > But if you just need something to _store_ the file, > > not to _process_ it, it could be an option for you. > > I don't know about the specific scenarios you're > > preparing for, but as you talked about IMAP data > > in maildir format, I can imagine that you just could > > transfer a tar file from the "Windows" system to the > > actual IMAP server (for data restore), extract it > > _there_ - which will surely be some kind of UNIX > > system (FreeBSD, any BSD, Linux), and every UNIX > > system has a tar implementation. > > > > Just a thought. > > > > Summary: You cannot use FAT for backups when it will > > not allow the filenames to stay the same. > > > > I am using the word archives in its ordinary sense, a collection of > records. I am using the word record in its ordinary sense as well, > something that is preserved, not as a entry in a data file. I am not > referring to any specific file format or application software. > > The purpose of the USB key archives is to allow me to search for > specific files, generally UFT8 encoded, using the native file system > tools on whatever host I have access to. I do this on a regular > basis. Encapsulating the data in a file format that depends upon > access to a specific application defeats the purpose. Okay, this makes perfectly sense. So you do _not_ use those files to restore IMAP message content on the server you've rsync'ed them from, you're just unhappy with the fact that "12345." became "12345" on FAT due to naming restrictions. In this case, you can convince yourself that you didn't do anything wrong, it's just FAT that doesn't allow a "." at the end of the filename. Maybe it is possible to live with this fact, or try to change the source file naming convention from "xxxxx." to "xxxxx" (where x = 0...9), if that is possible. The "encapsulation" would probably add more inconvenience in this specific case, because you cannot guarantee that it will be available on every system you will use to search your message archive. Just consider FAT as one of the lowest (!) common denominators in filesystem space. It has lots of restrictions you need to accept when you intend to use it. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...