Date: Tue, 29 Jan 2019 16:10:43 -0600 From: Noel <noeldude@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: RSYNC changes file name Message-ID: <b80e7e48-1b85-5091-3acc-16556a2aae4c@gmail.com> In-Reply-To: <e432756c72f160c62582a70a617da288.squirrel@webmail.harte-lyne.ca> 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> <e432756c72f160c62582a70a617da288.squirrel@webmail.harte-lyne.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/29/2019 3:35 PM, James B. Byrne via freebsd-questions 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. > > That's perfectly fine, as long as you're aware of the limitations when moving between file systems that have different filename rules. Also be aware that ms-dos type filesystems silently-internally case-fold names, so that "FOO" and "Foo" are the same file. This can lead to data loss by unintentionally overwriting a file. rsync can't warn of you the name munging since rsync asks the filesystem to write file "foo." and the filesystem says, "ok, sure"... so no error to report. If this is a regular thing, you would be well served to insure all the files you're saving conform to ms-dos name rules.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b80e7e48-1b85-5091-3acc-16556a2aae4c>