Showing posts with label email. Show all posts
Showing posts with label email. Show all posts

Sunday, February 19, 2012

Windows 7: Thunderbird: Add Security Exception

I was using Mozilla Thunderbird 10.0 for email.  I suddenly got this message:

Add Security Exception

You are about to override how Thunderbird identifies this site.

Legitimate banks, stores, and other public sites will not ask you to do this.

Server Location:  imap.exchange.iu.edu:993

Certificate Status

This site attempts to identify itself with invalid information.

Wrong Site

Certificate belongs to a different site, which could indicate an identity theft.
Below that, there was an option to "Permanently store this exception" and buttons to Confirm Security Exception or else Cancel.  Canceling didn't achieve anything:  the same dialog came right back.  I was afraid to click anything else.  The site in question was linked to Indiana University, which seemed legit.  I had gotten something like this before, using an earlier version of Thunderbird, but there the problematic email account had been Hotmail.

I wasn't sure why I was getting this.  A Mozilla page said, "The problem usually arises when the mail server's certificate is invalid for some reason. . . . Often this problem takes care of itself, in that the mail server provider will realize that they have made an error with their certificate and will replace it with a corrected version."  I had started getting this program maybe a year earlier.  I didn't know if this meant that I was the only person at Indiana University using Thunderbird, or what the explanation might have been.

I didn't find anything on point in Indiana's knowledgebaseA search led to advice to make a change in Server Settings.  To get there, I had to click Cancel with the "Permanently store this exception" box checked; otherwise the dialog wouldn't budge.  Even so, I had to click Cancel a bunch of times to get out of there.  I went into Thunderbird > Tools > Account Settings.  I went to the Server Settings heading under the listing for the Indiana University account on the left side.  The advice seemed to be that, in that area, I should go to the Security Settings area and set Connection Security to None, instead of its present setting of "SSL/TLS."  Doing that changed the Authentication Method from "Normal password" to "Password, transmitted insecurely."

I wasn't sure about that.  I looked further down that same thread.  Someone else seemed to be saying that the address should be imap.exchange.iu.edu.:993, with a period before the colon.  Staying in the Account Settings dialog, and looking specifically at the list of options on the left side, I moved from the Server Settings option down to "Security," the last option for the Indiana University email account.  There, I went into Certificates > View Certificates > Servers tab.  I saw that I had certificates here for Mozilla, Google, Yahoo, etc.  It seemed like a legitimate list.  I decided to go with the advice, which was to go into Add Exception and type https://imap.exchange.iu.edu.:993.

Before I finished that, I took another look at the Mozilla page.  They said that the mail server provider (i.e., IU) should provide the necessary connection information.  They said that the Add Security Exception option that I was just about to finish would make my email through that account nonencrypted and visible to third parties.  Writers in another recent thread indicated that they, too, were having this problem.  The list of certificates (for e.g., Google, Yahoo) seemed to indicate that they had done what was necessary to provide email security at some level, but Indiana University had not.  I tried another search, but it led to surprisingly few hits, among which the main relevant reaction was puzzlement.

The Mozilla page seemed to be saying that you have three options in this kind of case.  You can ask the mail server people to get it together.  You can add a security exception -- or, as it appeared in my case at least, you would have to add a security exception if you wanted the program to be usable.  Or you could switch to a different account.  I wasn't sure whether switching to a different email program would provide another possible solution.

Sunday, December 18, 2011

Converting Email (EML) Files to PDF - Another (Partial) Try

Once before, I had converted individual email messages in EML format (from Thunderbird) to PDF format.  That had been a long and complicated process that I'd had to revisit a few weeks later.  It was now time to export some more emails from T-bird.  I decided to look for a simpler approach.

In the first stage of this inquiry, I was working with some EML files that had already been exported.  So this post starts halfway through the process.  The ordinary starting point, exporting emails from T-bird, appears later in this post.

Conversion Approaches

A thread gave me some ideas to play with.  It seemed that an EML, renamed to an HTM, could be opened in Internet browsers (e.g., Firefox) and also in editors (e.g.,  Microsoft Word, Wordpad).  Unfortunately, an email's header, containing the most recent sender, recipient, date, and subject information, was not inclined to print properly.  Some of the programs reviewed in the previous post would print the header with funky colors and other formatting stuff I didn't want.  Some would also produce tiny print.

I was able to produce better-looking output by changing the EML to an HTM extension and opening it in Notepad.  At the end of each line in the header, and twice more after the header, I inserted <br /> and then saved it.  Now it would open in Firefox with a halfway decent appearance.  There were also some lines in the header that I wanted to remove, technical lines other than the customary To, From, Date, and Subject lines.

The question was how to automate these changes.  I saw that Notepad++ would do changes for all opened files, but I didn't want to have to open large numbers of emails.  I found indications that a one-line Perl command and also an editor called TexFinderX would change all occurrences of certain text within multiple documents, but I didn't want to change all occurrences.  I wanted to change the first occurrence of "From:" to be "<br />From:" and likewise with Date and Subject, and I wanted to make other changes as well.

A search led to another Perl command that would apparently perform at least some of these tasks.  It was tempting to try to pick up enough Perl fluency to make that command work.  I decided, though, that it would be better to start by learning Perl more thoroughly (someday), so as to have a clearer understanding of what this command might or might not be doing inside some large number of files.  The search led, similarly, to various SED and AWK commands, with the same reservations on my end.

For some reason, it felt safer to use a utility programmed to achieve the same thing as those command-line approaches, even though I would still not be able to see what was being changed.  Maybe it was just reassuring to think that someone with programming knowledge was trying to solve the problem.  It helped to find a Gizmo recommendation for ReplaceText (formerly BK ReplaceEm).  My faith was shaken, however, when I saw that the Gizmo recommendation, dated October 17, 2011, was pointing to a webpage that said ReplaceText was no longer supported and "has known problems with some Windows 7 installations."  Not the end of the world, but also not ideal.  Gizmo's second recommendation was A.F.9, which appeared to have been last updated in 2002.  It seemed I might have to come up with some other approach.

Dealing with Headers

Another problem I was dealing with was that not all emails had the same kind of header.  Some had at least a dozen lines, with references to things like "X-Message-Delivery," where others had a smaller set of header lines.  It appeared that a fully automated approach could easily make a mess.  I noticed, for instance, that the Birdie conversion program would just run multiple lines together, in files with some kinds of headers.

Having spent a lot of time undoing messes caused by the previous EML conversion process, I decided to take a slower and more cautious approach, at least for starters.  I began with FIND commands, on the Windows command line, designed to distinguish EML files with different kinds of headers.  These FIND commands ran into Access Denied errors, resolved in a separate post.

It turned out that emails could contain a variety of header fields.  Some (e.g., Date, From, Subject) were essential and self-explanatory.  Others (e.g., Content-Type) were evidently common but were not ordinarily displayed in email readers (e.g., Outlook, Hotmail, Thunderbird).  Another category was the X-field.  According to one source, "X-fields are experimental [though evidently X was intended to stand for "extension," not "experimental"] fields added by email clients or servers and may be useful valid information or may be forged."  Things seemed to have changed since 1993, when someone seems to have felt that X-fields were to be "strongly discouraged."  At this point, they were widely used.  I had seen a number of them.  They were also called X-headers.  There was apparently no authoritative list of them; people were seemingly free to invent them as they saw fit, perhaps by using ordinary email programs (e.g., Eudora).  I found lists of X-headers for Usenet and listserv posts.  After some hunting, I did finally find a list of X-headers that might appear in email messages, as well as a discussion of standard HTTP header fields.  By this point, though, it was clear that any such list had to be open-ended.  Even that lengthy list did not contain some of the X-headers that appeared in one of the first emails I looked it (i.e., headers of the X-Message variety).  I found no clear indication of what headers might appear in a legitimate email message.

So apparently I was not going to be able to rely on someone's preconceived list of headers, as a guide to removing the unwanted ones from a large number of emails en masse (perhaps using some tool like TexFinderX, above).  The most reliable approach would seemingly require me to identify the header fields actually used in the emails I wanted to convert.  There did not seem to be an automated way to do that.  Some emails had HTML codes or empty lines dividing the two, but others did not.  I worked up an approach using screenshots, one per file (viewed in Notepad), to give me an impression of those codes.  But attempts to use optical character recognition (OCR) software on those screenshots did not give me an ideally reliable indication, in text, of the header contents.

It seemed that I probably had the ability to use macros in Word to eliminate unwanted headers and to reposition the wanted headers within the body of the email message, so as to produce a good appearance when the file was then printed to PDF.  (I was using Bullzip as my PDF printer.)  I decided to approach that project by whittling down the size of the messages -- that is, by removing attachments first.

PDFing the Attachments

I had a sample set of 46 EML files.  I was not sure how many had attachments.  A look at some of them in Notepad suggested that not all EMLs announced the presence of attachments in the same way.  It did seem, though that a certain text string would be found in most cases where an attachment existed.  That string was:

Content-Disposition: attachment;
On that starting hint, I ran a FIND command to see which of these 46 EMLs appeared to have attachments:
find /i /c "Content-Disposition: attachment;" "D:\Emails\*" > Attachlist.txt
Attachlist.txt gave me output like this:
---------- D:\EMAILS\FILENAME.EML: 1 
apparently indicating that FILENAME.EML contained one occurrence of the Content-Disposition text string.  It said that maybe a third of the files had one such occurrence, with the rest having none.  An exception:  one file contained two occurrences.  I looked at it.  It seemed to be a case of a forwarded message, with the ATT00001.htm filename that I had often observed but never did understand.  The message was displayed in the EML, but was also apparently attached in that ATT format.  My guess was that the best approach would be to keep everything up to the last occurrence of the Content-Disposition string.

I used Excel to convert Attachlist.txt to a batch file that would move the files containing Content-Disposition to a separate folder.  Then I opened all of the EMLs to see how accurate this FIND command was.  It appeared that I had found the key to distinguishing those files that did contain attachments:  the ones with "Content-Disposition: attachment;" did contain attachments, and the others did not.

I opened the EMLs containing attachments and manually printed their attachments as PDFs, with names that would help me link them to the emails later.  Some of them were extraneous winmail.dat attachments that I ignored.  Some were already PDFs and thus didn't need to be printed to PDF.  So now, in that separate folder, I had about a dozen EMLs that contained attachments, and about a half-dozen attachments that I had just PDFed from those EMLs.  I wanted to convert those EMLs to PDF first, and separately from the larger group of non-attachment EMLs, so as not to get confused as to which emails the attachments belonged to.  (More precise naming of the PDFs would have alleviated that concern, but would have taken more time.)  So now it was time to figure out a solution for the EMLs themselves.

Removing Attachment-Related Material from EMLs

My original plan was to get the EML into Microsoft Word, where I could write macros to manipulate the text in useful ways.  If I just opened an EML in Word, it would appear without its header.  That is, it would not look like an ordinary email, as viewed in Thunderbird or Outlook.  I could get around that problem by opening Word and setting it to Options > General tab > Confirm conversion at Open, and then open the EML as Plain Text, but that would be an extra delay.  With a lot of emails, it could be cumbersome.

I wanted to start by removing the contents of the emails that contained attachments, starting at the point of the last occurrence of "Content-Disposition: attachment."  Experimentation revealed that EMLs so truncated would still open and look fine in Thunderbird, and now they wouldn't have all that attachment material to prevent them from functioning like HTML files.  If they had more than one attachment, an attachment notice would still appear at the bottom of the Thunderbird EML screen, but I was OK with that.

It occurred to me that it might be possible to find a text editor with macro capabilities, so as to handle multiple tasks without having to cycle through multiple programs.  This led to a separate search for a suitable text editor.  In a development that would doubtless provoke some to cheer and others to weep, I wound up with Emacs.  In that process, I did manage to develop an Emacs macro that would eliminate, from an EML file, the post-HTML attachment material.

I was only working with a dozen or so EMLs in that pilot test.  I wound up combining the extracted attachments and manually produced PDF printouts of the truncated EMLs (viewed in Thunderbird) manually, so as to remove this potentially complicating part of the larger EML-to-PDF project.

Regular EMLs:  A First Pass in Emacs

Now I was able to focus on the headers, without worrying about attachments.  I had a group of 34 EMLs, with various kinds of headers, that I wanted to manipulate into printable HTMs.  I opened 15 of them in Notepad and took a look.  I decided to take them in batches.  The first kind, the simplest, had "To: " as its very first four characters.  These seemed to follow a pattern of separate lines for To, Date, Subject, and From lines, which I would keep, followed by Content-type, MIME-Version, and Content-transfer-encoding lines, which I would discard.  The four keeper lines would be moved down into the text, immediately after the BODY tag, with <br /> tags added for line breaks as needed.  I manually edited one of these in that way, opened it as an HTM, and it looked good.

As I thought about it some more, I thought that possibly a better strategy would be to write a macro that would go down to the <BODY> tag and then search upwards for the desired tags (From, To, etc.) and delete everything else.  And then, as I thought about it still more, I realized that all of the above were beyond my present Emacs ability.  I would get there ... but not today.

Tuesday, December 6, 2011

Windows 7: Adding Hotmail as Default Email in Firefox 8.0.1

I was using Firefox 8.0.1 in Windows 7.  (Apparently these instructions would also work for Firefox 3.0.)  I was looking at a webpage containing an email address.  I clicked on the email link and got a dialog saying this:

Launch Application

This link needs to be opened with an application.
Send to:
Thunderbird
Yahoo! Mail
Gmail

Choose an Application

Hotmail was not on the list.  But I wanted to use Hotmail.  To find a solution, I did a search and wound up with some advice on the process.  I decided to save a writeup of the advice here because it took me a while to find it.

The advice was to type "about:config" in the Firefox address bar, hit Enter, type "gecko" into the Filter box, and double-click on the first item on the list.  This was the item called "gecko.handlerService.allowRegisterFromDifferentHost."  Double-clicking on it put it into boldface and changed its value from false to true.  Then I closed the about:config tab.  I went back to the address bar and typed this command, all on a single line:

Javascript:window.navigator.registerProtocolHandler("mailto","http://hotmail.msn.com/secure/start?action=compose&to=%s","Hotmail")

and then I hit Enter.  This gave me a bar at the top with the question, "Add Hotmail (hotmail.msn.com) as an application for mailto links?"  I clicked on "Add Application."  That gave me a blank screen.  I went to Tools > Options > Applications.  There were a bunch of items listed there.  I went down the Content Type column until I found "mailto."  I selected it.  This gave me a drop-down menu on the right side.  I selected the "Use Hotmail" option and clicked OK.

I went back to the webpage where I saw that email link.  I clicked on that link.  This opened up the Hotmail sign-in webpage.  I signed in.  Hotmail immediately started an email addressed to that email address.  I composed and sent an email.  It seemed to go OK.  Problem solved.

Tuesday, August 31, 2010

Exporting from Thunderbird, Importing into Thunderbird

I was using Thunderbird as my e-mail program in Ubuntu.  I decided to switch to using Thunderbird 3.1 for Windows as my e-mail program.  It seemed, at this writing, that most people who were transitioning to Thunderbird were going toward Ubuntu, not away from it.  So in this post I am writing up some things that I had to figure out along the way.

I decided to switch to Thunderbird for Windows because I was planning to keep Ubuntu as my underlying operating system, but to focus my applications on Windows XP, which I would be running in a virtual machine in VMware.  This arrangement, I found, gave me dual-boot advantages without having to reboot.

I was particularly interested in using the portable version of Thunderbird as my Windows XP e-mail application.  This would enable me to take my e-mail and my address book with me on a USB flash drive.  The discussion of Thunderbird for Windows in this post relates specifically to the portable version.

After setting up Thunderbird Portable on a Windows computer and making a backup copy, I went into Ubuntu and simply copied over my data.  I found the relevant data in Nautilus (i.e., Ubuntu's File Browser, the equivalent of Windows Explorer), in this location:  Home Folder / .thunderbird / 6abstqrst.default.  (The 6abstqrst part of that name was apparently generated at random, and as such would have a different name in other installations.  Point is, it's the "default" folder.)

I copied that entire default folder to a USB jump drive and compared its subfolders, item by item, to those on the computer where I had installed Thunderbird Portable.  (Of course, I did these and other folder manipulations (below) while Thunderbird was *not* running.)  The comparable e-mail account data seemed especially to be located under the Data\profile\Mail folder.  Thunderbird's Address Book seemed to be in Data\profile\abook.mab.  The Address Book copied and worked without any problem.  The following discussion focuses on problems in getting the e-mail accounts to work correctly.

The simple process of copying e-mail accounts over seemed to work well enough.  I copied all of the folders from Ubuntu via my jump drive to the corresponding Thunderbird folders on the Windows machine.  I kept backups and did this rather painstakingly.  After replacing the contents of one subfolder in Thunderbird Portable with the contents brought over from Thunderbird for Linux, I would start up Thunderbird Portable and make sure that it still seemed to be functioning OK.  Through this process, I ended up with a Thunderbird Portable setup where the desired e-mail accounts did exist.  This may have been helped by the decision to run Thunderbird's Tools > Import option, which I did somewhere along the way.

When I was done, unfortunately, the e-mail accounts that showed up when I ran Thunderbird Portable were still not showing the contents that I wanted them to show.  For example, my Hotmail account was there, but its Inbox was empty, whereas the Hotmail Inbox on Thunderbird for Linux had contained a dozen e-mail messages.  I could see, moreover, that the Data\profile\Mail\pop3.live.com folder contained an Inbox that was 96MB in size.  That was larger than I would have expected, and in any case much larger than an Inbox containing nothing, which is what Thunderbird Portable was showing me.

It seemed that Thunderbird Portable was recognizing the e-mail accounts themselves, but was drawing the contents of those accounts from the wrong place.  I verified this by removing the entire Mail subfolder from Thunderbird Portable.  When I started it up, it was still seeing the same few old items in the same accounts.  I thought it might have observed or figured out where I had moved the Mail folder, so I removed it from that computer entirely; yet Portable was still seeing those same ghostly remnants of some previous state of my Thunderbird for Linux installation.

It took a bit of effort to figure out where those ghostly remains were hanging out.  Portable wasn't drawing them from Data\profile\Cache; they persisted even after I emptied that.  To find the answer, I started Portable, changed the system date to a year in the future, copied one of those old e-mail messages from one folder to another, changed the system date back to the correct year, and exited Portable.  Then I copied the entire Portable folder to a workspace folder elsewhere on the computer, and searched for files bearing that future year's date.  Aside from cache files and scripts, there turned out to be only a handful of files dated in that future year.

That effort led to the discovery that the Data\profile\prefs.js file that I had brought over from Ubuntu was not suited for Windows.  I went to the original backup of my Thunderbird for Windows Portable and copied its prefs.js file to the Portable installation that I was tinkering with, thus overwriting the Ubuntu prefs.js file.  Both of them began with a warning:  "Do not edit this file."  Instead, the warning said, I could follow the instructions provided on a webpage that, as it turned out, was no longer in existence.  A different webpage did advise me to edit prefs.js directly.  Again, of course, I would want to do this while Thunderbird was not running; and if there was any doubt about that, Windows Task Manager (Ctrl-Alt-Del > Processes tab) would confirm whether there was an instance of thunderbird.exe or ThunderbirdPortable.exe currently running.

I opened prefs.js in Notepad, widened the Notepad window to prevent lines from wrapping, and took a look.  I decided I didn't know exactly how to edit prefs.js, so I tried the alternative that the instructions at the top of prefs.js seemed to prefer:  I started Firefox, typed about:config in the address line, and looked to see what was there.  (Note that I did not have any other copies or versions of Thunderbird installed on that computer, else things could have become very confusing.)  I searched for instructions, and eventually realized that it might not make sense to use about:config to change system preferences for a portable program.

So I tried another search.  This led to a webpage that led, eventually, to a mozillaZine webpage that advised me to start over and try using the Kaosmos ImportExportTools utility.  So I made a fresh start, replacing my munged-up Thunderbird Portable with a copy of the backup, and then I installed the ImportExportTools utility as instructed.  Then, in Thunderbird Portable, I went to Tools > ImportExportTools > Import mbox file.  At this point, I had to ask myself:  What, exactly, is an mbox file?  A search led to the discovery that mbox is an e-mail storage format that didn't seem very relevant to Thunderbird's own storage format

To test this, I went ahead with where I was in the ImportExportTools process:  I selected the "Select a directory where searching the mbox files to import (also in subdirectories)" option, and pointed it toward the top level of the folder I had copied over from Ubuntu Thunderbird.  To my surprise, the tool asked me if I wanted to import various programs.  I said no to parentlock and yes to all the other folders it asked me about.  After asking me about those folders, it didn't seem to be doing anything, except that I could see movement in the green progress bar at the bottom of the screen.  When it seemed to be finished, I didn't see any change in Thunderbird's list of folders.  I killed and restarted Thunderbird.  Still no change.  I poked around and then, whoa, I discovered that it had imported everything, including my archives, into the Hotmail Inbox folder (not the actual online one -- just the copy of it that Thunderbird keeps).  I killed T-bird again, made a backup copy of this remarkable state of Thunderbird Portable, restarted the program, and began moving and rearranging folders.

This was looking good, but there were still some things to fix.  First, in T-bird Portable, I tried sending a message that I had kept in the Hotmail drafts folder in Thunderbird for Ubuntu.  I got this message:

Send Message Error
Sending of message failed.
An error occurred sending mail.  Unable to establish a secure link with SMTP server smtp.live.com using STARTTLS since it doesn't advertise that feature.  Switch off STARTTLS for that server or contact your service provider.
A search and then a refined search led to the quick answer that I just had to stop my avast! antivirus software from scanning outgoing messages.

Next, I wanted to get rid of some Local Folders, especially the Inbox and Outbox.  I found a thread that made me think these folders were a product of Smart Folders, which would supposedly combine all of my e-mail inboxes into one Inbox, etc.  I did not want this.  Actually, I wasn't sure this was even the correct explanation, because I was seeing new incoming messages in my Hotmail Inbox, and they were not being mirrored in my Local Folders Inbox.  The advice I got from Yahoo! Answers, usually a font of goofy bewilderment, was as follows:
You can't remove the Smart Folders account using Tools -> Account Settings. You need to either edit prefs.js with a text editor or use the Config editor to delete the account from mail.accountmanager.accounts.
I was inclined to believe this because I had just run across another webpage with more or less the same conclusion.  But the advice on that webpage was oriented toward deleting all local folders, whereas I was using the Local Folders heading as the place to park my e-mail archive.  I right-clicked and saw, from Properties, that Outbox folder was located at Data\profile\Mail\Local Folders\Unsent Messages.  I quit T-bird, made a backup copy of the whole T-bird Portable folder, went into that Local Folders folder in Windows Explorer, and deleted the Unsent Messages entries.  I then restarted T-bird.  No joy.  As expected, the Outbox was still there and the Unsent Messages entries were back.  A new search led to a blanket statement that you could not delete the Outbox because it served an essential function, different from a Drafts folder:  it held messages that the user had tried to send but (because of e.g., no Internet connection) had not yet actually been sent.

So I turned to the next problem arising from the import into Thunderbird Portable for Windows.  I now had two top-level folders appearing at the left side of the T-bird window.  One was for my Hotmail account; the other was for Local Folders.  There should have been a third one, for another e-mail account that had appeared as a top-level folder in T-bird in Ubuntu.  This seemed to be a simple matter of going into T-bird Portable > File > New > Mail Account and entering the information about the account as it was recorded in T-bird for Ubuntu.  But the Mail Account Setup process stayed stuck for a long time on "Looking up configuration:  Trying common server names."  I finally went into Manual Setup and got it working that way.  And with that, the project was done.  I had transitioned from Thunderbird (Ubuntu) to Thunderbird Portable for Windows.

Thursday, March 18, 2010

Critique of Mano & Mesch on E-mail at Work

In a previous post, I critiqued a 2003 article by Friedman and Currall entitled “Conflict Escalation: Dispute Exacerbating Elements of E-mail Communication.” This post reviews a more recent article that brings out several important parts of the Friedman and Currall argument.

Article Reviewed: Mano, R. S., & Mesch, G. S. (2010). E-mail characteristics, work performance and distress. Computers in Human Behavior, 26(1), 61-69.

I found this article through a search for a present-day review of issues mentioned in my review of Friedman and Currall, whom Mano and Mesch cite. To quote the abstract, Mano and Mesch conclude (p. 61):

Using a secondary level analysis based on the Pew and American Life sample we show that extent, content, and increased volume of e-mail are (a) more frequently reported by managers than by non-managers (b) age, gender, marital status and education can become a critical issue (c) the amount of e-mail received and sent is positively related to work performance. 

Like Friedman and Currall, Mano and Mesch examined e-mail at work. Their general question for randomly dialed survey respondents (n = 394) was “the extent to which ‘.... using e-mail for work-related tasks has changed your work life’” (p. 65). Using factor analysis, they identified three major areas in which e-mail might affect respondents’ work life: work effectiveness, work distress, and work stress. In their construction, “work effectiveness” was improved if the use of e-mail increased the number of people communicated with, improved teamwork and awareness of current work events, saved time, and made the respondent more available to his/her colleagues.

“Work distress” involved the extent to which e-mail provided moments of relief, encouraged gossip, and made it too easy for people to reach the employee. “Work stress” asked whether e-mail made it impossible to get away from work, caused misunderstandings, was distracting, or added new sources of stress. Thus Mano and Mesch did not restrict their focus to the potential dispute-enlarging aspects of e-mail that had interested Friedman and Currall, but rather placed the alleged dispute-enhancing tendency into a context that took account of potential benefits of e-mail usage. Hence my critique of Friedman and Currall anticipated something similar to what I found in Mano and Mesch.

Mano and Mesch investigated four hypotheses, which boil down in general terms to the hunches that work effectiveness, stress, and distress are correlated with greater e-mail use (in terms of both time spent on e-mail and numbers of e-mails sent and received) and frequency of e-mail checking, but stress and distress are inversely correlated with the number of non-work¬related e-mails. I did not find their distinction between stress and distress to be either intuitively clear nor empirically crucial in most cases, and in this discussion thus sometimes adopt their reference to both as dimensions of “employees’ wellbeing” (p. 68) or other quality-of-life phrasings. Moreover, since they found that “e-mail with personal content neither contributes to work performance, nor is it detrimental,” and since personal e-mail was not in any event the core issue in their research, I will not focus on non-work-related e-mails. With these adjustments, their research hypotheses may be roughly phrased as the suggestion that greater e-mail use and frequency of checking is positively correlated with work effectiveness and negatively correlated with employee wellbeing. And this is essentially what they found.

The authors sought to nuance that suggestion with attention to several additional characteristics. Among such characteristics, they determined that organization size is negatively related to frequency of e-mail checking, and that numbers of e-mails are greater for managers than for non-managers. Mano and Mesch attribute the decreased well-being for employees that arises from increased e-mail usage to “information overload” (p. 68), where such overload emerges not only from the information management aspects of receiving numerous e-mails (e.g., understanding, storing, and retrieving) but also from the new tasks, priorities, and interactions required by the contents of such messages.

In addition to the limitations identified by the authors (namely, the limited number of variables available to their secondary data analysis, lack of sensitivity to occupation and task, and inability to distinguish technological and non-technological environments), I had some concerns. On a stylistic level, I was not reassured by the typographical errors and poor grammar, and I found it unhelpful that the authors would occasionally refer to undefined constructs (e.g., “better working time,” p. 66) whose meaning I could not readily ascertain. On a more substantive note, I was not impressed with the paucity of current research. On a subject as novel and evolving as e-mail (in e.g., a Facebook era), it is certainly strange for an article published in 2010 to draw upon a number of works from the 1980s (not to mention 1958), or to refer to a 2003 study as “recently published” (p. 63).

In terms of overall structure, I was not sure how the authors’ three research questions translated into their four research hypotheses, nor was it entirely clear to me that they rigorously worked through each of those hypotheses. For example, while their interest in the well-being of managers is worth noting, their concluding focus on it gave the impression that they had gotten distracted. I also found that some of their conclusory editorializing did not follow from their research. Indeed, in their remarks that “at the end of the day, work is done by people, and it is due to their individual wellbeing that work performance improves,” I thought I detected a contradiction of their apparent sense that e-mail-related well-being and performance tend to operate at cross-purposes. Nor was I persuaded that stress and distress are “undesirable” outcomes of work performance (p. 63); stress seems to be a work performance motivator in many circumstances. Most egregiously, for purposes of the present review, I was not impressed with the authors’ summary statement that unspecified “researches [sic] have shown that information conveyed via e-mail nurtures negative aspects of communication” (p. 68). I had thought that they intended, themselves, to look into e-mail as a generator of misunderstandings. I did not expect to see that notion resurrected in the conclusion if it did not emerge profoundly from their own data.

Despite such concerns, it did appear that Mano and Mesch provided a solid review of relevant literature. For purposes of learning about conflict management, this literature review (which actually began in the article’s introduction) was more informative than their own empirical research. They cite various sources for several propositions: that e-mail imposes a degree of technical neutrality insofar as very different people are compelled to communicate in a basic lingua franca, for example; that other data sets (unlike the one they used) permit differentiations among kinds of e-mails (e.g., announcements, task information); and that e-mail has the potential for multiplying positive interactions among individuals, including many who might otherwise not even become aware of one another.

Generally, it is worth considering that what e-mail opens is not Pandora’s box but is, rather, the door to the future. That is, there is a pervasive assumption that the workplace dare not become entangled in personal issues. So the personal difficulties and interpersonal conflicts of normal life become an 800-pound gorilla that everyone tries to ignore. This worked to some extent in an industrial era, especially when mental focus was not an essential ingredient in job performance. It does not work nearly as well in mentally challenging positions. It would be possible, in theory, to treat e-mail as an identifier of issues to be resolved – as, in other words, an exposer of what was previously swept under the rug. It seems that a mentally healthy workplace might coexist well with a commitment to deep, long-term integration of its participants. In that case, when Mano and Mesch observe that “e-mail has been found to generate negative outcomes as well such as ‘politicing’ and ‘petty tyranny’” (p. 62) – as if e-mail were the cause of, rather than merely an outlet for, office bullying. The analysis would be more persuasive if one were to take account of the productivity of workplaces in which there is no awkwardness-inducing device (e.g., e-mail) by which people can intentionally or inadvertently highlight barriers to growth and improvement.

Thursday, February 18, 2010

Critique of Friedman & Currall on E-mail

Article Reviewed

Friedman, R. A., & Currall, S. C. (2003). Conflict escalation: Dispute exacerbating elements of e-mail communication. Human Relations, 56(11), 1325-1347.

Summary of the Article

Friedman and Currall (2003, p. 1327) discuss situations in which exchanges of e-mail messages exacerbate conflict.  The topic arises because of their experiences and observations of instances in which a disagreement that seemed minor and manageable escalated, via e-mail, into serious conflict, to the point of ending relationships.  They ask:  “[I]f e-mail communications that exhibited conflict escalation had occurred by phone or in person, would they have ended as they did?”  This question is important because, they say, “as the number of workplace relationships managed by e-mail increases, the implications of e-mail escalation will grow exponentially.”

The authors explain this escalation in terms of their “dispute-exacerbating model of e-mail” (DEME) (p. 1325).  Their explanation is apparently a “model” in the sense that it is “a description or analogy used to help visualize something (as an atom) that cannot be directly observed” (Merriam-Webster Online, 2010).  In this case, the model seems to consist simply of elaboration upon the view that e-mail can exacerbate disputes.  The discussion here will thus tend to refer to this as simply a view or an idea, rather than as a formal model.

Friedman and Currall identify four dispute-exacerbating characteristics of e-mail:  it provides diminished feedback, it provides diminished social cues, it can be lengthy, and it can attract excess attention from the parties.  The first two of these four seem more or less identical:  as the authors explain, e-mail does not provide an opportunity for the kinds of clues that people tend to give each other when they are conversing face-to-face or by phone.  Because of this dearth of feedback, people are more likely to misconstrue one another’s views and perceptions, especially in the direction of perceiving that the other party is behaving aggressively.  E-mail does not give people the same opportunities to understand and get to know one another, and to emphasize the importance of openness and cooperation in their interactions.  Other people are depersonalized and more easily seen as oppositional.  E-mail also provides less information about social status, along with “weak cooperative norms and weak restraint against using aggressive tactics” (p. 1336).

The authors’ third identified dispute-exacerbating characteristic of e-mail is that the ability to go on at length, in an e-mail message, carries a risk of provoking unnecessary misunderstanding and disagreement.  Long messages can be seen as rude and overwhelming.  They may result in responses that address only a few points, which may then be seen as dismissive.  Moreover, the authors say, attention may go especially to the most negative arguments, and compounded misunderstandings in an exchange of e-mails make it “harder to unravel the differences between the parties” (p. 1338).  The fourth dispute-exacerbating characteristic, excess attention, again seems to make a similar point:  people can be drawn too far into an e-mail exchange, resulting in the production of long replies and/or excessive rumination on what has been said:  “Thus, having the opportunity to focus a great deal of time on a received message may not be productive” (p. 1339).  Likewise, the opportunity to spend more time on the first message in an exchange means that one is more likely to become convinced of its truth and less likely to compromise; and the recipient is said to be more likely to assume that the sender has indeed made use of the opportunity to devote time to the message, so that its misstatements tend to be received as final statements of the sender’s firm intentions, as distinct from mere slips of the tongue.

In their conclusory section, the authors offer some advice for managing disputes.  First, they say, this is better done by phone or face-to-face than by e-mail.  If conflict management is done by e-mail, they recommend awareness to the foregoing conflict-aggravating characteristics of e-mail.  In the case of lengthy e-mails, for example, they suggest breaking the discussion down into multiple short messages, “generating as much interaction back and forth as possible” (p. 1342).  In their recommendations, they include considerations that were not, but perhaps should have been, added to the four dispute-exacerbating aspects mentioned above, especially focusing on the relationship rather than the message and avoiding “hyper-rationality” by remembering that “differences occur, and are resolved, through appropriate emotion not solely logical argument” (p. 1342).

Finally, the authors provide some caveats.  They say (p. 1344),

There are probably additional technologies that we have not covered (e.g., chat rooms), other effects of e-mail that we have not considered (e.g., the long-term impact of having written records), and other conditions that we have not explored (e.g., number of parties involved in the conflict).
They also acknowledge that e-mail is “extremely useful” and “does not turn all communications into escalated conflicts” (p. 1342), and “perhaps – over time – most people may become more skilled in e-mail” (p. 1343). 

Critique

While the authors make a number of valid points, I find that they neglect some important characteristics of e-mail in conflictual situations.  The following paragraph address those characteristics briefly.

First, a bit about my perspective.  I started using RSTS e-mail at Columbia in the late 1970s, and continued with CompuServe and other e-mail services in the 1980s and thereafter.  In the early 1990s, I worked at a federal agency that utilized e-mail to connect people in a half-dozen regional offices around the country.  Later that decade, I was active on Usenet newsgroups via Deja News and otherwise.  This background means that I have had many opportunities to make the sorts of mistakes that Friedman and Currall describe, and also to be on the receiving end when others have done likewise.  So when I review this article, I have reactions on both sides of the matter.

A basic assumption in this article is that the conflict, whatever it is, should be resolved rather than exacerbated.  Resolution, for Friedman and Currall, seems to mean softening and downplaying, with the aid of social norms and cues, so that a person will not say something via e-mail that s/he would not have said in person.  This makes sense in the context of an example like the one with which they begin the article, where a conflict unnecessarily spiraled out of control to the point of terminating a relationship.  But it also raises a number of questions.

One question is why the relationship in that instance was terminated.  The relationship in question apparently involved an editor of a scholarly journal and a writer who had submitted an article.  The conflict seems to have involved revisions requested by the editor.  According to the authors (p. 1326), “Each side had been presenting arguments back and forth until the editor . . . e-mailed that he was ‘ending our relationship.’”  In that instance, e-mail seems to have been facilitated the exchange of views between people who disagreed.  Should the parties have attempted to conduct that exchange via telephone?  Friedman and Currall are probably correct in implying that it would not have continued for long via phone – but why not?  The answer is, surely, that the editor occupied a position of power vis-à-vis the writer, and in a spoken conversation the writer would have received cues that the editor was displeased.  Being a sensible person, the writer would have had to take a submissive posture and allow the editor to have his/her way.  Instead, what may have happened was that the writer’s opportunity to think about and express his/her arguments via e-mail produced some conviction that those arguments had merit, and the editor was simply not willing to acknowledge his/her error.

This example provides a dubious guide for social workers.  First, it is not at all clear that social workers should invariably take a submissive posture when they confront people in positions of power about matters in disagreement.  Moreover, the opportunity to articulate and present one’s concerns can be enormously empowering, especially when one would be afraid to do so in conversation, or would simply lack any opportunity to do so because of cultural or organizational barriers.  For example, an e-mail may get forwarded to a top executive in instances when the writer him/herself would not be invited to speak to that executive.

Friedman and Currall (p. 1331) say that e-mail will escalate the level of conflict if it encourages the use of more aggressive tactics, produces a change in one’s view of the other, weakens interpersonal bonds, or makes problems more difficult to resolve.  This is precisely what e-mail does, they say, via the dispute-exacerbating characteristics cited above:  diminished feedback and social cues, and excessive verbosity and attention to detail.  But there is a straw man here.  These remarks assume a quality of face-to-face interaction that is often nonexistent.  There are people who dislike one another, who are bullied, or who for other reasons find it unpleasant to interact with another person face-to-face.  There are jealousies and unintended as well as intended offenses in remarks that people make to one another.  It can be harder to save face and maintain self-respect when an aggressor chooses to deliver such remarks in a context where the recipient has no opportunity to respond.  Again, contrary to what these authors say, interruption and denying the other person a chance to explain him/herself is more likely in face-to-face interaction than in e-mail, where one generally has at least the possibility of expressing oneself.

What seems to happen is not that e-mail somehow unmasks an evil side within each of us.  The more likely scenario is that, when there is a disagreement, it is attributable – as Friedman and Currall say – to a departure from a social norm.  But social norms are not intrinsically good.  They can easily incorporate or support aggression, prejudice, violence, and other types of dysfunctionality.  Much of what the authors say about e-mail is compatible with the possibility that e-mail permits people to present their concerns in ways that some such norms suppress.

One important assumption in the argument presented by Friedman and Currall is that social norms are restricted to face-to-face interactions.  But there has not been, in fact, the nationwide escalation of e-mail-based conflict the authors seem to fear.  People have become accustomed to e-mail and have developed new norms around it.  Sitting at a keyboard does not liberate one from social norms; more likely, it just invokes an adapted set of norms.  As in other kinds of interactions, these norms are not homogeneous:  some people will say things that others would not, each for reasons of self-protection, articulation, comity, or whatever they consider important in the particular situation.  These choices seem to reflect what people have found feasible and appropriate in their use of e-mail.

There is also a collective aspect to conflict, insofar as the straightforward presentation of concerns by one person may strain relations between the sender and the recipient, but may also nudge the recipient toward being more receptive when others present similar concerns.  In this case, to put the shoe on the other foot, perhaps the writer finds it difficult to learn from editorial criticism.  If so, the experience of running full-tilt into several brick walls may provoke some salutary reflection and growth, where the experience of simply giving in to the person with superior power may leave him/her muttering under his/her breath, ready to make the same mistakes in his/her next editorial interaction.  Conflict can be instructive.  Even in work contexts, and even when it leads to ruptures, it is not always a bad thing.

There is also an efficiency concern.  Editors frequently disagree with writers on various points.  The anecdote would have been more telling if it had been provided along with information about the larger context.  If the editor handles a hundred authors within a certain timeframe, perhaps a small percentage of those will carry disputes to an extreme, but most presumably do not, else editors would probably not use e-mail.  In the anecdotal situation, the editor probably did not need that particular author very badly, given that journal editors tend to be buried in article submissions.  What the writer apparently did not keep in mind, as s/he was crafting his/her replies, was that s/he was dispensable in this particular arrangement.

These observations highlight the educational aspect of e-mail conflict.  Turnage (2008) lists characteristics of e-mail messages that are highly likely to be considered “flaming.”  These characteristics include angry uses of profanity, all capital letters, and excessive exclamation points or question marks.  As suggested by the foregoing remarks about social norms, people tend to learn that these sorts of messages are ineffective if not counterproductive.  As users have become more familiar with flaming, they seem to have become more individually and collectively resistant to it.  In online discussion forums, for example, disputes featuring such behaviors tend to be abandoned by people who have no strong interest in either side of the argument, leaving those who do, along with those who would mediate – which may be an entirely appropriate outcome, especially if it does facilitate interaction among people of opposing who would otherwise be preaching to their own respective choirs.

I’ll rest that line of argument with the general statement that e-mail conflict management is more nuanced and valuable than the authors allow.  On a different level, it seems important to report the results of a bit of fact-checking.  I looked into a 1991 article by Clark and Brennan entitled “Grounding in Communication.”  Friedman and Currall cite this article for the view that grounding is the process in which parties to an interaction develop shared senses of understanding and participation, and “this is important because ‘speech is evanescent’” (p. 1328, quoting Clark & Brennan, p. 128).  This, it turns out, is not an accurate report of the earlier article.  Contra Friedman and Currall, the 1991 article states, not that there are “six tools for grounding” (F&C, p. 1328), but, rather, that there are eight constraints that a medium may impose upon people (C&B, p. 140).

Friedman and Currall do acknowledge that e-mail has an advantage in the last two of those eight, reviewability and revisability, but they don't make clear that Clark and Brennan differentiated “grounding in conversation” (p. 128) from grounding in other sorts of communications.  Clark and Brennan cite the “keyboard teleconferencing” of their time as an example where grounding was indeed attainable, although acknowledgments were more “costly” because they would take more effort (because, in their era, “it is difficult to time an acknowledgment precisely, and trying to do so may interrupt the other typist”) (p. 140).  That is still a problem in chat, but much less so, because chat is very fast now, and its users tend to become used to it.  At any rate, acknowledgment is probably less of a problem in e-mail than in face-to-face conversation, where people often do not show that they have even heard, much less comprehended, what the other party has said.

On the fact-checking level, it also seemed to me that Friedman and Currall somewhat distort the matter when they criticize e-mail for permitting the use of certain “tactics” that are not available in ordinary face-to-face communications.  One is what they call “argument bundling,” where “e-mail comments can be very long and include multiple points . . . . without the receiver having the opportunity to respond or clarify” (p. 1329).  Of course, speakers at conferences and rallies have been doing this for millenia.  It is not a tactic; like e-mail, it is simply a mode of communication, with its own significant advantages for some purposes.  The difference is not its one-sidedness; it is that recipients tend to be self-selected to agree in the public meeting context.  That difference is important and interesting, but it is not explored in this article.

Actually, recipients of long e-mail messages do have opportunities to respond in ways of their preference.  For instance, they can break long messages into smaller pieces and explain that, for lack of time or interest, they are responding, but for now, as a courtesy, will respond at least to the first several sentences or paragraph of the message they received.

One final fact-oriented rejoinder:  e-mail, according to Friedman and Currall, is “profoundly asocial” (p. 1329).  Were this true, social media would have been stillborn.  The more accurate statement, I suggest, is that e-mail is social in ways that are unfamiliar to those who have not yet added it to their repertoire.  One thing the authors consider particularly asocial about e-mail is that “E-mails are typically received and written while the writer is in isolation, staring at a computer screen – perhaps for hours at a time, so that awareness of the humanness of the counterpart may be diminished” (p. 1329).  This is not necessarily true; e-mails are typically written in a variety of situations and, when they involve the workplace setting that the article sometimes cites as its focus, isolation is atypical.  Staring at a computer screen may or may not have the effect of diminishing awareness of the humanness of others; but if it does, this problem goes well beyond e-mail to the entire arrangement and even the viability of many contemporary, computer-dependent workplaces.  Indeed, if awareness of humanness is to be prioritized, it is not clear that the coldly efficient market economy itself can survive.

The article by Friedman and Currall turns out to have been interesting but unidimensional.  Email and other electronic communications do have drawbacks in conflict management situations.  There will be conflicts that go bad in e-mail, that would have turned out better in other media.  This is true of all forms and styles of communication and interaction.  People are best advised, not to run pell-mell away from e-mail when conflict emerges, but rather to become more familiar with its advantages and to implement strategies that help them to minimize its drawbacks.

Tuesday, December 29, 2009

Basic Ubuntu (Bash) Shell Scripts

In Ubuntu 9.04, I wanted to write a script that would execute an rsync command, so that I could put a brief reference to the script into my crontab file, instead of putting the whole long rsync command there.

For a brief, tiny moment, I was almost tempted to consider learning the GAMBAS (Gambas Almost Means BASIC) programming language, just because (pre-Visual) BASIC was the only programming language I ever learned.  Instead, I moved toward basic instructions on writing a shell script.  Here's what I wrote:

#!/bin/bash
# This is backup-hour.sh
# It backs up CURRENT to CURRBACKUP every few hours
rsync -qhlEtrip --progress --delete-after --ignore-errors --force --exclude=/.Trash-1000/ --exclude=/lost+found/ /media/CURRENT/ /media/CURRBACKUP

As the instructions said, the first line was essential to tell the computer to use BASH to interpret the following lines.  The next two lines were comments, and the final line (wrapping over onto multiple lines here) was exactly the rsync line I'd been using to do the backup.  In other words, learning how to write the command was almost all I needed to write the script.

The next step was to save it somewhere.  I had previously heard, and the instructions said, that the common place to put it is in your bin folder.  I went with that, but made a note that I would need to be sure to back up my bin folder, because I didn't want to go to the trouble of writing all these scripts and then see them vanish.

The usual location for the user's bin folder is at /home/[username]/bin.  In my case, that's /home/ray/bin.  Getting there in Nautilus (i.e., Ubuntu's File Browser, also started by typing "nautilus" in Terminal) can be confusing:  you can get there via the Home Folder option (assuming you're showing Tree rather than Places or something else (or nothing) at the left side of the file browser), or you can go to File System/home/[username]/bin.  Same thing, either way.  So I saved the script (above) in my bin folder as backup-hour.sh.  That turned the comment lines (beginning with #) blue in gedit.

Next, the instructions said, I needed to set permissions.  This was a confusing aspect of Ubuntu.  The documentation seemed to say that there were ten permissions that a person could set.  These were represented by ten hyphens or minus signs:  ----------.  I couldn't tell what the first one was for, but the remaining nine were divided into three sets of three.  The first three belonged to the owner, the second three to the group, and the last three to "other."  Within each set of three, the first one was for read, the second was for write, and the third was for execute (i.e., run it as a program).  So if you set the owner's permissions to read (r), write (w), and execute (x), your ten hyphens would now change to this:  -rwx------.  If you set all three parties (i.e., owner, group, and other) the same, they would look like this:  -rwxrwxrwx.

You could set the permissions using the chmod command.  I found an Ubuntu manual page on chmod.  It was not really that complicated, but it looked like it was going to require a time investment to make sure I had it right, and at this point I was getting impatient.  The basic idea seemed to be that you could use chmod to enter values of 4 (for read permission), 2 (for write permission), and/or 1 (for execute permission).  So, for example, you could type "chmod 755" and that would give a value of 7 to the first of the three users mentioned above (i.e., the owner), a value of 5 to the second of the three (i.e., the group), and a value of five to the third of the three (i.e., other).  The 7 would mean that you gave read + write + execute (4 + 2 + 1) permissions to the owner, whereas the 5 would mean that you gave only read + execute (4 + 1) permissions to the rest.  Since that's what the instructions suggested, I went with that.  To set the script with those permissions, I typed "chmod 755 backup-hour.sh."

I wasn't too sure of who the owner was (i.e., me or root), not to mention the group or other.  I mean, this was for my home computer.  Not a lot of people milling around, waiting to take my hard drive for a spin.  These kinds of options seemed to be set up for networked computers, where the "accounting" department might be a group that would own a file.  I found what looked like a good tutorial on file owners, and another interesting (yawn!) page about permissions, but fortunately I did not have time to work through them.

When I typed "chmod 755 backup-hour.sh," I got "cannot access 'backup-hour.sh': No such file or directory."  One solution was to use a change directory (cd) command to get the Terminal prompt into the bin subfolder, so it would see what I was looking for.  But since I planned to put more scripts into that folder, and anyway since I wanted cron or other programs to know right away what I was talking about when I referred to something like backup-hour.sh, I decided to figure out how to put the bin folder in my "path."  The path is the list of folders where the operating system looks for guidance on what a command means.  To change my path so that the system would always know to look in bin, they said I needed to find and edit my .bash_profile file.  Unfortunately, they didn't say where it was.  It wasn't easy to find.  I ran searches in Nautilus (both user and root), but while those were grinding away, I found that I could just type "locate .bash_profile."  That turned up nothing, but very quickly.  Then I got some advice that, if it didn't exist, I could create it by using "touch ~/.bash_profile."  So I did that, and then tried again with "chmod 755 backup-hour.sh."  Still no joy.  Ah, but maybe that was because I hadn't rebooted; backup-hour.sh would run only on startup.  OK, so I used the other approach after all:  I changed directory to the bin folder and tried again.  Now I got "Permission denied."  What if I gave everybody full permissions with chmod 777?  I tried that instead of chmod 755.  That seemed to do it.  The hard drive was doing its thing now.

I wanted to see what was going on, so I decided to create a log file.  I wanted it to store only the error messages, not to list the thousands of files that backup-hour.sh was backing up successfully, so I put this on the end of (that is, on the same command line as) my rsync command in backup-hour.sh (above):
2> /media/CURRENT/backup-hour.log

The log filename thus matched the script filename.  I put "backup" first so that I could see all of my backup scripts in the same part of the folder's directory listing, and then I set up a backup-day.sh script along the same lines.  New problem:  these backup scripts would generate empty log files if there were no errors, and I didn't want to have to delete them manually.  So I found a forum post with advice on how to delete them automatically, using the "find" command.  In my version, it looked like this:
find /media/CURRENT/ -name "*.log" -size 0c -exec rm -f {} \;

I put that at the end of the backup-day.sh script, and it seemed to work.  It said, basically, look in the CURRENT folder for files whose name ends with .log and have zero bytes; and if you find any files like that, execute the "remove" command without asking for permission.  I didn't know what that ending punctuation is about, but that's what the advisor suggested.

In my backup-day.sh (not backup-hour.sh) script, I included the instructions for updating my USB jump drive (above).  I also included a set of commands to save my e-mail (I was using Thunderbird in Ubuntu) as a .tar compressed file. Actually, as seven .tar files, one for each day of the week.  That part of backup-day.sh looked like this:
# Assign Thunderbird mail & profile to be backed up
backup_files="/home/ray/.mozilla-thunderbird"
dest="/media/BACKROOM/Backups/Tbird"
# Create archive filename
day=$(date +%A)
hostname=$(hostname -s)
archive_file="$hostname-$day.tgz"
# Back up to a tgz file
tar zcvf $dest/$archive_file $backup_files 2>> /media/CURRENT/A-INCOMING/T-bird-Backup.log
So these seemed to be the basic kinds of tools I needed to set up rsync scripts and crontab entries.