Closed GoogleCodeExporter closed 8 years ago
macbookpro03:~ gjp22$ cd /Volumes/
macbookpro03:/Volumes gjp22$ ls -l
total 8
lrwxr-xr-x 1 root admin 1 May 1 02:38 MBP -> /
d--------- 1 root wheel 0 Jan 1 1970 keeler
d--------- 1 root wheel 0 Jan 1 1970 omnium-gjp22
I used Finder eject to remove from
/Volumes
the directories that had not removed following use of the Eject button
presented by MacFusion.
macbookpro03:/Volumes gjp22$ ls -l
total 8
lrwxr-xr-x 1 root admin 1 May 1 02:38 MBP -> /
Original comment by grahampe...@gmail.com
on 1 May 2007 at 8:15
Used MacFusion to re-mount both volumes.
Consider the directory listing for keeler, which hosts one of the two test
documents that I had been editing:
macbookpro03:/Volumes gjp22$ ls -alt keeler/
total 8408
drwxrwxrwt 6 root admin 204 May 1 09:17 ..
drwx------ 1 gjp22 111 1024 May 1 07:33 Mail
-rw-r--r-- 1 gjp22 111 82 May 1 07:32 ._Winnov queries copy.doc
drwx--S--- 1 gjp22 111 2048 May 1 07:31 .
-rw------- 1 gjp22 111 4036 Apr 30 19:31 .sh_history
-rw-r--r-- 1 gjp22 111 75326 Apr 30 10:53 2007-04-30 welcome Rosie
Mulgrue.pdf
drwxr-xr-x 1 gjp22 111 96 Apr 28 11:43 159
-rw------- 1 gjp22 111 12292 Apr 28 11:30 .DS_Store
-rw-r--r-- 1 gjp22 111 82 Apr 27 04:00 ._JORUM_osswatch_final.doc
-rw-r--r-- 1 gjp22 111 3871232 Apr 27 04:00 JORUM_osswatch_final.doc
-rw-r--r-- 1 gjp22 111 82 Apr 20 12:26 ._Winnov queries.doc
-rw-r--r-- 1 gjp22 111 53760 Apr 20 12:26 Winnov queries copy.doc
-rw-r--r-- 1 gjp22 111 53760 Apr 20 12:26 Winnov queries.doc
-rw-r--r-- 1 gjp22 111 455 Apr 14 14:25 .mlbxlsttmp
[snip]
I find it curious that I had successfully used Word to save changes this
morning to
Winnov queries copy.doc
but only
._Winnov queries copy.doc
bears today's date.
Original comment by grahampe...@gmail.com
on 1 May 2007 at 8:26
A comparison
The time-sorted listing for the directory (on the other server) that hosted the
other document presents a
slightly different picture...
macbookpro03:/Volumes/omnium-gjp22/Documents gjp22$ ls -alt | more
total 9136
drwx--x--x 1 gjp22 staff 3672 May 1 07:32 .
-rw-r--r-- 1 gjp22 staff 82 May 1 07:32 ._2005-11-05 Windows XP
post-installation errors copy.doc
-rw-r--r-- 1 gjp22 staff 395264 May 1 07:32 2005-11-05 Windows XP
post-installation errors copy.doc
-rw------- 1 gjp22 staff 82 May 1 07:31 ._Word Work File L_3
drwxr-xr-x 1 gjp22 staff 2142 Mar 6 18:57 ..
-rw-r--r-- 1 gjp22 staff 82 Mar 3 12:09 ._Hello again.doc
[snip]
That seems more logical, both
._2005-11-05 Windows XP post-installation errors copy.doc
and
2005-11-05 Windows XP post-installation errors copy.doc
modified this morning.
Original comment by grahampe...@gmail.com
on 1 May 2007 at 8:29
http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/394001754831?
r=687008984831#687008984831
> auto unmount on sleep is a wonderful, wonderful thing?
> No more beachballs
Original comment by grahampe...@gmail.com
on 11 May 2007 at 1:08
See also MacFUSE issue
http://code.google.com/p/macfuse/issues/detail?id=173
Original comment by grahampe...@gmail.com
on 11 May 2007 at 11:14
MacFusion issue 86 regarding limitations of sshfs is a
HIGHLIGHT
in the context of this issue 25
and other novel/unexpected uses of the sshfs system in general
(not the sshfs-static binary in particular).
Original comment by grahampe...@gmail.com
on 12 May 2007 at 10:15
I opted to test with
> auto unmount on sleep
and an application that is likely to be less stressful than Microsoft Word
2004.
1) Preparing for my journey from home to office
2) Apple menu | Location | I changed location
3) I didn't watch for the brief disconnection that is usually observed
in 'IP in menu bar' (at this point in this test, a disconnection would probably be irrelevant)
4) I waited for a moment
5) MacFusion 1.1 Beta 2 | Favourites | omnium-gjp22
(an ssh connection to my home directory on that server)
6) TextWrangler | File menu | Open recent |
index.html - /Volumes/omnium-gjp22/Sites/2007/05/13
7) I edited the file
8) I did not opt to save
9) Apple menu | Sleep
10) I waited for the LED on my MacBook Pro 17" to begin pulsing
11) I closed the lid, LED continued to pulse
12) I removed the Ethernet cable, LED continued to pulse
13) I journeyed to work
14) I connected my Cinema HD display to the DVI port
15) I connected an Ethernet cable
16) I connected the power adapter
17) at this point the laptop awoke
18) TextWranger | command-s | changes were saved to the file :)
19) I command-clicked the proxy icon in the title bar of the file
20) I released at /Volumes/omnium-gjp22/Sites/2007/
21) TextWrangler | command-w
22) I opened the lid
23) display menu icon | Detect Displays
24) TextWrangler | File menu | Open recent |
index.html - /Volumes/omnium-gjp22/Sites/2007/05/13
25) I edited, saved changes, success :)
After each saves I browsed to
<http://omnium.freeman-centre.ac.uk/~gjp22/2007/05/13/> and reaffirmed that
saved changes to
index.html were apparent. They were.
SUCCESS :)
My next step should be to test using something more stressful. Microsoft Word
comes to mind.
Original comment by grahampe...@gmail.com
on 14 May 2007 at 8:44
Priority-Critical
as my current sense is that if
Unmount on Sleep, Remount on Wake
is NOT a default
THEN there may be a greater risk of users finding themselves unable to save
changes -- to documents that
they were editing before a computer slept -- after the computer has woken.
We already have
Label:Component-Docs
— when we're more certain about this (I have some more testing to do) we
might provide documentation/Help
warning against (and better explaining the possible implications of) certain
Sleep/Wake preferences.
Original comment by grahampe...@gmail.com
on 14 May 2007 at 8:48
We (I) should also check to see what might happen as a result of the brief
disconnection that sometimes occurs
when a location is changed (in software). For example: will a brief
disconnection such as that have an effect on
unsaved changes to Microsoft Word documents? (Could be a separate issue in due
course.)
Original comment by grahampe...@gmail.com
on 14 May 2007 at 8:51
Since I have preferred for MacFusion to
Unmount on Sleep, Remount on Wake
I can no longer reproduce the issue of Word (or TextWrangler) failing to save
changes to files that were edited
(but unsaved) prior to sleep.
As a critical suggestion (to avoid loss of data by users):
Unmount on Sleep, Remount on Wake
should be the default, with explanatory Help/documentation.
Unless, that is, there's a good reason to default to some other sleep
behaviour.
Thanks
Original comment by grahampe...@gmail.com
on 15 May 2007 at 9:38
For reference only: here are the notes that I entered into the Word document as
I was editing, saving etc.
during the test:
1. tt connecting via SFTP (sshfs) to omnium, MacFusion 1.1 Beta 2
2. editing this document with Word 2004 on Mac OS X 10.4.9
3. Save — successful
4. OK so far
5. edit some more
6. sleep
7. Growl notified me that
* MacFusion failed to Unmount the volume
8. displays went blank
9. pulsing LED to confirmed sleep
10. disconnected from Ethernet
11. reconnected to Ethernet
12. wake
13. Save — successful
14. edit some more
15. intention:
a. sleep, disconnect, reconnect, wake
b. change location
c. observe the brief disconnection (IP in menu bar application)
that is typical for this particular change of location (from Automatic to Freeman Centre)
d. attempt save as soon as IP in menu bar indicates that
connection is re-established…
e. SUCCESS!
Original comment by grahampe...@gmail.com
on 15 May 2007 at 9:45
For the benefit of any reader who is alarmed by
> MacFusion failed to Unmount the volume
in my previous comment, that is separated into issue 109 (apparently, not a
defect).
Original comment by grahampe...@gmail.com
on 15 May 2007 at 10:04
This morning I performed similar tests and had to wait maybe ten minutes,
following a wake and a (soft)
change of network location, for unresponsiveness to end. Details to follow and
in the meantime, for the
record:
<http://pastie.textmate.org/62024> (sshfs-static open files and ports during
*unresponsive* time)
<http://pastie.textmate.org/62025> (sshfs-static open files and ports *after*
responsiveness returned)
<http://pastie.textmate.org/62023> (sshfs-static sample *after* responsiveness
returned)
<http://pastie.textmate.org/62026> (extract from console.log
<http://pastie.textmate.org/62027> (extract from system.log)
Attached: a debug log that may assist with any one of, or combination of,
MacFusion
issue 25
issue 109
issue 116
The Word document with which I was testing was ultimately saved successfully,
and I Quit from Word with no
apparent problem.
The lengthy period of unresponsiveness was undesirable but as it was ultimately
possible to save changes to
my Word document, and to Quit from Word thereafter, at this point I still veer
towards
Unmount on Sleep, Remount on Wake
as a default.
Original comment by grahampe...@gmail.com
on 16 May 2007 at 11:11
Attachments:
See also
MacFusion issue 118
Original comment by grahampe...@gmail.com
on 16 May 2007 at 12:07
Again, this morning, I performed tests. On both occasions saves were
successful.
This morning's successful tests with Word were followed by:
* a very long wait after I clicked the eject icon against the volume in Finder
sidebar (Continue to Wait etc. in
the dialogue from MacFUSE level)
* Activity Monitor and IP in menu bar (application) unresponsive during that
wait (issue 118)
* a requirement to Force Eject, and continued running of the sshfs-static
process (issue 119).
The most remarkable thing was the illogically short length of time that it took
for Word to open a large
document over a relatively slow connection. For this, I'll raise a separate
issue.
(Whilst focusing on Word, I don't forget the utility and limitations of SSHFS
as a system.)
Original comment by grahampe...@gmail.com
on 16 May 2007 at 5:45
Re my comment 13 above, here are three snapshots that I took during that wait
(for responsiveness, after
waking, at the MacFUSE level) before a save was possible.
I remind myself that at points during the wait (in my judgement, at that time,
*not* too soon after the wait
had begun) I experimented by:
# enabling AirPort (without letting it become the primary connection, to the Internet)
# then removing the Ethernet cable (allowing AirPort to become my connection to the Internet).
Key points (?)
* Ethernet cable was connected, and AirPort disabled,
prior to waking the computer
* I waited for a reasonable length of time with a
fast (100 Meg) link to the same switch (Z-PoP) to which
the server (Mac OS X Server 10.3.9) is connected
* some time (I shan't estimate how long) after
enabling AirPort then removing the Ethernet cable
(allowing AirPort to make my connection to the Internet)
Word became responsive and allowed me to save changes
without difficulty.
Original comment by grahampe...@gmail.com
on 16 May 2007 at 6:11
Attachments:
Sleep wake issues to be address before 1.1.
Original comment by mgorb...@gmail.com
on 17 May 2007 at 3:41
I'll test again very shortly.
In the meantime I'm bookmarking
<http://www.macosxhints.com/article.php?story=20070517224112286>
which discusses the
kicker
daemon.
Original comment by grahampe...@gmail.com
on 22 May 2007 at 1:06
This is now the ONLY blocker bug on 1.1.
Hopefully Graham and Michael can talk tomorrow to resolve this, and 1.1 is go.
Original comment by mgorb...@gmail.com
on 22 May 2007 at 4:00
I'll test once more in a few moments,
> Unmount on Sleep, Remount on Wake
and report back.
Original comment by grahampe...@gmail.com
on 22 May 2007 at 9:23
As I suspected, it does seem that working with Microsoft Office documents in
general (I shan't limit my
cautions to Word 2004) is a lottery.
Ultimately on this occasion
> Word failed reading from this file...
> [Cancel] [[Retry]]
And when I eventually Cancelled (gave up retrying), long after the connection
to the ssh connection to the
remote system had been restored, Word crashed.
Word crash report is at <http://pastie.textmate.org/63499> and I didn't bother
sending it to Apple.
If we begin to fine tune sshfs, MacFUSE or MacFusion for a moving and (IMO)
poorly documented target such
as Word, then we place ourselves on the edge of a precipice.
My sense is that we should acknowledge -- and present clearly to the end user
-- the limitations of
_systems_ such as sshfs in a FUSE environment (and explain, without
finger-pointing, that it's not a problem
with MacFUSE, sshfs-static or MacFusion).
Let's discuss :)
Original comment by grahampe...@gmail.com
on 22 May 2007 at 10:30
> a moving and (IMO) poorly documented target such as Word
Brace yourselves. In an MSDN blog
<http://blogs.msdn.com/rick_schaut/archive/2004/05/19/135315.aspx>
someone explains why it can be so difficult to identify and fix bugs.
Original comment by grahampe...@gmail.com
on 22 May 2007 at 10:41
Per conversation with Graham, tagging as WONTFIX right now.
To be addressed later.
Original comment by mgorb...@gmail.com
on 22 May 2007 at 2:40
Avoid a long system lockup related to sleeping shares
<http://www.macosxhints.com/article.php?story=20070522053721530>
-- I don't know whether anything there will be relevant in the
MacFUSE/MacFusion contexts but at least, there
are people interested in the subject generally.
Original comment by grahampe...@gmail.com
on 23 May 2007 at 9:30
See also MacFusion issue 145.
Original comment by grahampe...@gmail.com
on 23 May 2007 at 1:23
At
<http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/341003745831>
<http://episteme.arstechnica.com/eve/forums/a/tpc/f/8300945231/m/800002745831/p/
2> and elsewhere
there are differing interpretations of what autofs will bring to Mac OS X 10.5.
At <http://www.apple.com/macosx/leopard/technology/unix.html>:
> The Finder and other applications needn’t wait for one mount to
> complete before requesting another
-- whilst some people may understand this to mean 'no more Finder beach balls'
in the broadest sense, I
focus on the word 'mount'.
When we sleep our computers and/or change networks — necessarily disrupting
SSH and other connections —
there's much more going on than a simple mount.
I wonder: should we _expect_ file systems such as SSHFS, which depend upon
networking, to behave
gracefully when the network is disrupted?
(If behaviour is graceful, that's a bonus, but should we _expect_ it?)
Bearing in mind:
* SSHFS, CurlFtpFS etc. are described as 'utility' file systems
* historically, protocols such as AFP have greater consideration for network
disruption etc..
<http://groups.google.com/group/MacFusion-devel/browse_frm/thread/
5b412e06839f7609/479222d09de746a8> invites discussion.
Original comment by grahampe...@gmail.com
on 17 Jun 2007 at 8:14
At <http://ircbrowse.com/channel/macfusion/20070618#hour23> positive comments
re: wake from sleep
Original comment by grahampe...@gmail.com
on 18 Jun 2007 at 10:59
Original issue reported on code.google.com by
grahampe...@gmail.com
on 1 May 2007 at 8:11Attachments: