Most of the comments received were along the same lines.
But still , even if there are backup tools that can handle
such files and files with special characters, you must admit
that there is a sufficient hassle in dealing with such files
as to make them not worth the effort.
My solution is to modify my backup C program, to put " "
around all of the file names.
My manager did agree to only have files with non standard
names, not directories. So I only have to modify my incremental
program. But I still do not agree with using spaces and other
special characters in file names, if it truely were OK to use
them then ALL of the Unix tools including shell commands and others
would be able to use them OK, but such is not the case, and I am
sure that it will cause further problems as time goes by.
But when I do not have the support of my manager, then I have
no choice but to comply.
Thanks to all for your responses:
john_w@mentec.ie
Does your backup back everything else up? If so, I would take the approach
of telling these users that their directories will not be backed up, and
let them suffer the consequences of any lost files.
You could "accidently" delete a file from one of these directories,
just to illustrate the point :-}
P.S. My users think I'm a total facist.
--------------------------------------------------------------------------------
Sam_Shaffer@gilbarco.com
Marc -
These happen a lot, not necessarily intentional. All it
takes is a slip of the finger or brain. Mostly, I fix 'em
as I find 'em or as customers complain of "lost" or un-readable
files.
Best way I've found to determine the actual name of an object
is 'od -c' command. Just smack that against a directory
od -c dirname
and look closely at the results for \b (backspaces) \t (tabs)
and all our other non-straight-forward friends. Then use
wildcards to rename them. (mv bogu*sfile goodfilename).
P.S. - Unless I am dealing with system or general use files/dirs,
I always ask my customer first. It makes them think kindly
of me for doing them a favor, (we need all the good P.R.
we can get), and I also make sure I don't break something
they did with intent, or have already figured a work-around.
---------------------------------------------------------------------------------------
From: "Dean L. Eich" <deane@dtmr.com>
I had to deal with this at a previous site. The best way,
in my opinion, is to educate the user on file-naming conventions.
Tell them the hassle that comes with doing this on a
unix machine.
---------------------------------------------------------------------------------------
From: Joe Cornelius <joec@edge.net>
This isn't an answer to your question, but; it sounds like you have a very
illbehaved application that is allowing users to do this, I have heard of
this type of problem when a PC/MAC is NFS mounting a UNIX directory.
If it is an application and you can determine which one I would contact the
vendor for a patch if available, you need it so there probably isn't one. ;-)
Otherwise, write a script that can process the directory entries prior to
backup and strip-out all of the offending characters. I had to do this
many, many, many.... moons ago as a onetime fix due to the reason listed above.
---------------------------------------------------------------------------------------
From: Bill Hassell <blh@hpuerca.atl.hp.com>
It's much worse than you described. These files are mistakes and the
users canot even use the resultant files (try to list a file with a
space in the filename).
What allows this to happen are applications that are poorly written and
allow and string to be used as a filename. You probably can't fix that so
the only choice is too blow them away or rename them with a message to the
user that identifies the problem. Don't worry, you'll get a call from
users in the future asking how to delete or access these files anyways so
you might as well start fixing them now.
How do you detect a wrong filename? That will take a pretty sophisticated
script or program since you'll have to establish a set of unacceptable
characters (ie, any control chars) as well as imbedded special chars that
have meaning to the shell (ie, \}{)(*$# and so on). Then look for files
with these characteristics.
---------------------------------------------------------------------------------------
From: "Dave K. Lahoti" <dlahoti@qntm.com>
Change the file names.
I think that'll be easier than supporting it.
---------------------------------------------------------------------------------------
From: "Doug O'Leary" <71620.3561@compuserve.com>
I haven't had to deal with it, no; however, my knee-jerk reaction would be to
'rm $fname'. Unless there's a valid reason for naming files like that (and I
can't think of any), then the only thing they're doing is messing around with
your backups. They're causing immediate loss of time and productivity on your
part as you have to track down the errors in the backup process. If they're
maintaining any kind of important information in these files, then they're also
risking your company's assets by naming files thusly.
Since there's no logical reason for their naming scheme, and it's causing
problems, then I would feel compelled to remove the problem every time I
encountered it. Also, only the first or second time would I bother backing the
files up before I removed them.
But, that's just me... :-)
---------------------------------------------------------------------------------------
From: Mike Peterson (System Admin) <system@alchemy.chem.utoronto.ca>
I scan once a week for pathnames that contain blanks, CTRL/ALT characters,
or things like '...' which are often used by crackers to hide things.
I then fix the name manually, mailing the user to tell them what I
have done.
NOTE: for those that want the programs that Mike inclosed please ask for
them seperately, as they are a bit lengthy to include with this
summary.
/usr/local/bin/updatedb
/usr/local/bin/Getsystemoptions
/usr/local/bin/Getnfsdownlist
/usr/local/bin/findfile
---------------------------------------------------------------------------------------
From: Rachel Polanskis <rachel@juno.virago.org.au>
As a trainer, I am always trying to teach people
how MIME types work.
Your problem is similar to mine:
We have 50/50 PC and Mac users.
The Mac users are in the habit of writing filenames such as:
My New Year report & summary #4
(up to 32 characters)
When these files are sent as attachments using the internal email, to a
PC, th e file names are truncated and if the Document is say, a MSWORD
document, the file is not identifiable by MS Windows as an association.
I am forever searching peoples Hard Disks for files they said they had been sent,
but cannot find.
I send a general mail around every month or so to remind people
to stick to the MSDOS 8.3 file convention, plus a little guide to MIME types,
and the importance of the file extension in identifying these on certain
platforms.
I believe you have 2 options:
1: A general educational message to demonstrate a standard method of file
naming conventions.
2: A Disclaimer that states that if the conventions are not practised,
you will not be able to assure safe backup and recovery.
It is only by education that people will be aware of the problem....
Rachel
---------------------------------------------------------------------------------------
From: nobroin@esoc.esa.de (Niall O Broin - Gray Wizard)
I haven't had such a problem - I would have to say that your backup software
is at fault here - if it's a legal filename on a Unix filesystem, then any
backup software worthy of the name should be able to cope. Speak to your vendor
or if it's home brewed - physician, heal thyself. If you're dealing with
filenames in shell scripts, always quote them e.g. use
some_operation "$FILENAME"
instead of
some_operation $FILENAME
I say this fresh from a weekend playing with a bunch of files which were
created from Macs on a Unix box running netatalk - these files have spaces,
commas, quote marks, and even / characters in their names. The / is of course
not legal in a Unix filename so netatalk replaces it by :2f - I presume
netatalk replaces any non Unix legal characters by : and the hex value of the
character as : is not legal in a Mac filename. I was doing a lot of manipulation
of these files via scripts and I was caught quite a bit until I started always
quoting filename references.
Hoping this has been of some assistance,
---------------------------------------------------------------------------------------
From: ppc@inel.gov Pam L. Johnson
We had the same battle several years ago. The only solution
we found was if people wanted us to do their backups - then
they had to follow certain guidelines. If they didn't want
to follow the guideslines - we didn't backup their machines.
I don't know if you're set up this way - but that is what
worked for us.
---------------------------------------------------------------------------------------
From: Kevin Inscoe (CRC-LSG x2082) <kpi@hobbes.crc.com>
Well then I have to ask what backup program are you using?
I have Macs using NFS/Share and they store stuff like this all over
the place (3GB worth to be exact) and dump/restore (SunOS 4.1.3)
handle them just fine. There is one caveat though. In interactive
restore it will not cd into a directory with a space in the name even
if you wrap it in quotes. But no biggie I just restore the entire tree
and pluck out what I need and mv it from there.
See above on backups. Operationally I have never had a problem wth
these types of file names but they again this has strictly been from
NFS clients. We haven been doing it from unix but I can't imagine what
problems would exists strictly under unix but rather the other way
around.
---------------------------------------------------------------------------------------
From: allan@NMHG.com (Allan Warrior)
I usually only have this trouble with people new to UNIX. I tell them
that if they use any of the "shifted" numbers characters they are likely
to lose their file. It has not been much of a problem for me. I have
more of a problem with new persons that inadvertently move a file to
some obscure directory where I can not find it. Their "lost" file is
hard to find because they don't correctly remember the file name so that
grep and find can locate it. I do encourage my 20 users to at least understand
what a command line does even though most of them don't care to ever use
one.
---------------------------------------------------------------------------------------
From: "Lynne Pickett" <ebex@gdeb.com>
Our policy is you snooze you lose!
---------------------------------------------------------------------------------------
-- + ------------------------------------------------- + + +++ N E C +++ +++ A M E R I C A +++ + + ------------------------------------------------- + + Marc L. Summers System Administrator + + 3100 N.E. Shute Road Hillsboro Oregon 97124 + + PH: 1-503-681-3338 FAX: 1-503-681-3304 + + Email: marcs@tdd.hbo.nec.com + + ---------- Sic transit gloria mundi. ------------ + + --- "Thus passes away the glory of the world." -- + + ------------------------------------------------- +
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:52 CDT