samba, rsync --backup, and mangled instead of long filenames

Noel noeldude at
Fri Jun 20 01:12:57 UTC 2014

On 6/19/2014 5:22 PM, Dale Scott wrote:
> I've got backup files created by rsync in a Samba file share being served with mangled filenames to a Windows client. I suspect it's because I'm telling rsync to create backup filenames with colons in them and, since Windows doesn't allow colons in a filename, Samba has no choice but to serve mangled filenames. Does that make sense? Are there any _easy_ solutions?

Yes, the colons will break windows compatibility.

The easy fix is don't use colons, as in date +%FT%H%M%S
or maybe --suffix=`date +%FT%H%M%S`.dwg will work.

  -- Noel Jones

> Background - I'm using rsync and cron to nightly synchronize a local directory on an fbsd server with a Windows server share containing AutoCAD dwg files (among others). I'm using the rsync "--backup" option to preserve historical copies of files because the Windows users can arbitrarily modify files in their share (e.g. by updating a drawing from rev 1 to rev 2, overwriting the v1 file). Even if I could convince users to append the version to the filename, it could never be guaranteed.
> My rsync command line:
> rsync -aq --itemize-changes --include-from=rsync_mech_include --exclude-from=rsync_mech_exclude --backup --suffix=-`date +%FT%T` --log-file="/tmp/rsync.log" "/mnt/share/AutoCAD/16000-16999/"  /home/samba/mech/parts.rsync/10016000
> If e.g. file 10016342.dwg is created in the Windows share, copied by rsync to the local fbsd directory, then modified in the Windows server share, rsync renames the local 10016342.dwg to something like 10016342.dwg-2014-06-10T18:15:19 first, then copies the updated file.
> Ideally, I'd rather have backup filenames like 10016342-2014-06-10-T-18-15-19.dwg so they sort nicer and, because the extension is preserved, can be opened (read-only) from a Windows client. However, that's out of scope for --suffix. I could append ".dwg" in the suffix, but I have to deal with essentially arbitrary file extensions, and disassembling and reassembling file names on the fly simply seems like a bad idea, especially if a more out-of-box solution exists.
> Any suggestions?
> Dale
> ----
> Transparency with Trust
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

More information about the freebsd-questions mailing list