RSYNC changes file name

Polytropon freebsd at edvax.de
Tue Jan 29 20:44:02 UTC 2019


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. :-)



> I discovered this by trying to touch a file named 'seventeen.' which
> showed up as 'seventeen' instead.
> 
> It would have been nice to have that munging reported.

Inside the VFS tree, the copying process is handled
transparently, so rsync (or touch) do not get back
an error they could report. However, the "error" will
happen at the VFS driver (here: FAT driver) addressed
in the "deeper" levels of the VFS, so it would maybe
be possible to issue a kernel message which could be
shown on the console or at least in the system log.

Knowing about restrictions specific to filesystems
is important for the FAT and NTFS drivers to keep
the r/w mounted filesystems in a consistent state;
using "forbidden filenames" can cause the strangest
effects in "Windows"... ;-)

NUL:



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list