Force Eject required following successful Quit from Word 2004 (suspect that Word does not properly 'release' remote files on sshfs volume

[GoogleCodeExporter]

After 
<http://code.google.com/p/macfusion/issues/detail?id=25#c11> 

I saved changes to a document that I had edited using Word 2004. 

Save: successful. 
Quit from Word: successful. 

In Finder, I clicked in the sidebar the eject icon alongside the volume. 

I was prompted to Continue Waiting (or Force Eject etc.).

Slightly off-topic: whilst waiting (with Finder beach balling, understandable) 
I took the 
opportunity to attempt to save changes to a previously unsaved TextWrangler 
document. As 
expected, TextWrangler beach balled in 'sympathy'. I mention this only because 
I suspect that in 
circumstances such as this, users may confuse an issue cause by one application 
(in this case, 
almost certainly Word) with symptoms present in another application (in this 
paragraph: 
TextWrangler). 

Back on topic to my problems after using Word with an sshfs volume: after 
waiting for some 
time, I opted to Force Eject. TextWrangler and Finder became responsive. 

We probably have no issue with MacFUSE or sshfs-static, but it could be noted 
that (in my 
experience) Microsoft Office can be notoriously problematic when it comes to 
'releasing' files in 
the proper way. More specifically: 

  * a successful Quit from Microsoft Word 

  * does NOT always equate to a release of 
    all files with which it has been working. 

At least, that's my experience through a few years of administering Mac OS X 
Server and AFP 
servers prior to that.

This, I suggest is something of which we should be aware, as users may 
misconstrue problems 
arising from extraordinary behaviour of Microsoft Office as some defect with 
MacFUSE or related 
technologies. 

At <http://code.google.com/p/macfusion/issues/detail?id=86> I have highlighted 
the 
comments regarding utility and limitations of sshfs but pending the adition of 
Help/
documentation within the MacFusion Project, I'm cautiously predicting that as 
use of MacFUSE 
etc. widens, so we might expect people to do stupid or unexpected things with 
systems (such as 
sshfs) that are not always appropriate for the user's purpose. 

(This is me stress-testing the various environments, predicting user stupidity 
and figuring how 
best to deal with it. Absolutely *not* finding fault with MacFUSE :)

Original issue reported on code.google.com by grahampe...@gmail.com on 15 May 2007 at 10:02

[GoogleCodeExporter]

Force eject isn't "required".

If you're seeing that alert panel, all that means is that the user file system 
took longer than the default 
timeout (20 seconds). This could be because there was too much data to write 
and the link was too slow. It 
could be a bug in one of the pieces too.

Nevertheless, you do have the option of not force ejecting. The dialog gives 
lets you wait longer if you wish.

If you know that in your scenario, 20 seconds is not going to be enough of a 
timeout, you can change the 
value through the daemon_timeout option.

Original comment by si...@gmail.com on 15 May 2007 at 9:06

[GoogleCodeExporter]

We might choose a more descriptive Summary field for this issue :)

> could be because there was too much data to write

As I had used only two GUI applications with that volume: 

 # Finder (to browse, not to copy or move)

 # Word 2004 (to edit and successfully save an 
   existing Word document on that volume)

and as I had Quit from Word, without difficulty 

so _logically_ I expected *no* amount of data to be written to the server. Word 
saved. I Quit from Word. 
Period. 

(True, I took the opportunity to see how TextWrangler would behave in this 
situation, but I *had* waited for a 
more than reasonable period — I have a 100MB connection to the same switch 
(Zone-POP) to which our Mac 
OS X Server is connected — before adding TextWrangler to the equation. If 
Word was trying to do something, 
it had a *fine* connection and *more* than enough time to do it properly.)

Word is too often, for my liking, unpredictable — *not* logical — in its 
handling of open files, and (it seems to 
me) its failure to release its lock on files with which it has finished. 

Whilst I might test again with Word, I'm respecting the observation (MacFUSE 
issue 173) that sshfs is not a 
resilient distributed file system … so, I don't expect sshfs to cater for 
the peculiarities of Word. 

<http://www.google.co.uk/search?q=site:info.apple.com%20AFP%20%2BWord> hints at 
the number of issues 
that have been assocaited with Word and AFP. 

Sinking realistically into pessimism, for just a minute or two: 
I *certainly* do not hope for Microsoft to adapt its various versions of Word 
to cater for files systems other 
than the systems in which it has a vested interest. 

At <http://support.microsoft.com/kb/105153> <sigh> I find Microsoft's October 
2006 review of a (sic) 
knowledge base article that still incorrectly _equates_ AFP with AppleTalk. 
</sigh> <deep sigh> And (off-
topic but exemplary) I shan't seek the articles but I'm 99% certain that 
Microsoft still state that Mac OS stores 
file type/creator codes in resource forks. (Are not, or were not, the those 
codes stored as metadata on disk 
unrelated to resource forks?) This amongst other things probably explains why 
the most recently updated 
version of Word 2004 still writes ._ dot underscore files when saving to 
single-fork file systems. </deep sigh> 

## 

I don't intend to (hope I don't have to) pinpoint precisely the behaviours of 
Word/Office that might cause 
problem such as this. That's not a disinterest in contributions towards fixes; 
rather, it's my acknowledgement 
that sshfs may have its limitations and I seriously doubt that Microsoft will 
get properly their heads around 
innovations that are not their own!

That said, I keep an open mind :)

Original comment by grahampe...@gmail.com on 16 May 2007 at 3:29

[GoogleCodeExporter]

I'd put this discussion in the general category of "what do end users want if 
the user-space file system doesn't 
respond in time". I noted elsewhere that I might remove the alert panel 
altogether. I'm open to user feedback on 
macfuse-devel.

Original comment by si...@gmail.com on 8 Sep 2007 at 9:40

• Changed state: WontFix

[GoogleCodeExporter]

Re: the alert panel, noted and understood. Thanks. 

--

MacFUSE aside: re: circumstances _prior_ to the alert panel, broadly speaking I 
should have expected a volume 
to be ejectable after cleanly quitting an application that had edited a file on 
that volume. From past experience 
I might suspect Word as contributory, OTOH my recollections of files on servers 
mysteriously left open by 
Word may date back to the days of Mac OS 9 and AppleShare IP; perhaps I'm 
unnecessarily wary of Word...

Original comment by grahampe...@gmail.com on 9 Sep 2007 at 8:05