RSYNC changes file name
freebsd at edvax.de
Tue Jan 29 22:00:33 UTC 2019
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
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
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.
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions