Filename encoding and extended attributes

William J. Coldwell cryo+brackup at
Wed Nov 14 10:25:09 UTC 2007

I ran across a buglet due to some errant program I wrote years ago
that put a ^J into part of the filename.

-rw-r--r--   1 www  www     8192 Nov 30  2001 warped?.db

so in the metafile:

Path: www/htdocs/usage/OLD/warped
Size: 8192
Digest: sha1:ac4894cf3eb05c41e389c4dadbdb9d4b94c41cdb
Chunks: 0;8192;8192;sha1:ac4894cf3eb05c41e389c4dadbdb9d4b94c41cdb
Mtime: 1007181926
Atime: 1164770990

Path: www/htdocs/usage/OLD/warped.db
Size: 40960
Digest: sha1:43599ab916a04bb283690b074d3278aa2cf8b90e
Chunks: 0;40960;40960;sha1:43599ab916a04bb283690b074d3278aa2cf8b90e
Mtime: 1007181926
Atime: 1164770990

This breaks things kinda bad.  So I think that path should be
encoded/escaped (html?).  This would help destinations that are not
capable of handling character sets not latin1 (or even UTF8).

At the same time, I thought that extended attributes for filesystems
need to be handled as well (see XAR), for ones that have them, like
OSX's metadata forks... NTFS, Ext3(4)?

Thoughts?  Also, have an patches since 1.6 been made/accepted yet?  It's
been kinda quiet in here.

William J. Coldwell (Cryo)
Custodial Engineer
Warped Communications, Inc.

More information about the brackup mailing list