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.

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.

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.

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.