search

mahinthjoe / macfuse

Automatically exported from code.google.com/p/macfuse
0 stars 0 forks source link

alert the user if a non-recommended action is attempted (e.g. open a large .dmg on a remote file system) #209

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Request for enhancements below. I appreciate that they might be difficult or 
impossible to 
implement. Not a priority. 

Current Mac OS X behaviour - FTP - read-only
--------------------------------------------

Mac OS X | Finder | Connect to Server...
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk

Open (for example) the 16.5 disk image
firefox-3.0a6pre.en-US.mac.dmg

A warning dialogue appears, twice: 

> ! [alert icon + Finder icon]
> 
> The application "name.dmg" is on an FTP server. Are you 
> sure you want to open "name.dmg"?
> 
> [Cancel]  [[Continue]]

The disk image may take some time to mount, but it's graceful. 

After the image mounts: the application on the disk image seems to perform 
normally, without 
incurring unexpected network traffic.

MacFUSE with MacFusion and CurlFtpFS plug-in
--------------------------------------------

The disk image may take some time to mount, and the Keep Trying option may 
appear. Both fine. 

After the image mounts, an attempt to open the application on the disk image 
seems to result in 
unexpected network traffic. Ultimately, the process (in this example, 
firefox-bin) that I'm 
attempting to run from the disk image stops responding. 

##

I *do* understand that it's not recommended to open disk images of this size 
via FTP, but I 
wondered how MacFUSE etc. would compare with Finder etc..

===================================
Request for enhancements to MacFUSE
===================================

A user-friendly dialogue to alert the user, 
if the user attempts an action that is not recommended. 

1) The dialogue

> ! [alert icon + MacFUSE icon]
> 
> "ItemName" 
> is on a remote {type} server. Would you like to 
> download then open a local copy of 
> "ItemName"?
> 
> Remote items of this type may not open, or may behave  
> unpredictably, when opened from a {type} server. 
> 
> [Cancel]  [Open remote original]  [[Download a copy]]

Default button is 
[[Download a copy]]

Destination for download should be the destination set within Safari. 

I imagine that the {type} will not be limited to FTP.

2) On completion of the copy, maybe: 

a)  the parent directory of the copied file should be 
    opened in a Finder window 

b)  the copied file should be visible within the window pane

c)  beyond simple visibility: Finder should 
    _neither_ bring the window to foreground
    _nor_ select the copied file (I imagine that doing so 
    might, rarely, interfere with other scripted actions).

Environment
-----------

Mac OS X 10.4.9, Finder
MacFusion 1.1 with CurlFtpFS plug-in

Other thoughts
--------------

I first wondered whether [[Open remote original]] 
should be the default _if_ the remote original is in a 
read+write directory. Thoughts of sharing etc..

Then, reminded myself that FTPFS is a utility system.

Original issue reported on code.google.com by grahampe...@gmail.com on 4 Jun 2007 at 3:18

Attachments:

GoogleCodeExporter commented 8 years ago 
No, it's not a good idea to add such things or such knowledge to MacFUSE. Not 
yet, at least.

Original comment by si...@gmail.com on 4 Jun 2007 at 5:45

GoogleCodeExporter commented 8 years ago 
> "but I wondered how MacFUSE etc. would compare with Finder etc.."

Why would you compare MacFUSE with the Finder? They are completely different 
things at completely different 
levels. MacFUSE is a file system (a meta file system, if you will), whereas the 
Finder is a user interface atop the file 
system layer.

The kind of alert messages you are suggesting should be generated *before* the 
operation is attempted--not 
within the kernel.

Original comment by si...@gmail.com on 5 Jun 2007 at 9:26

GoogleCodeExporter commented 8 years ago 
> The kind of alert messages you are suggesting should be generated
> *before* the operation is attempted--not within the kernel.

OK - I may take these thoughts to the MacFusion area in due course. 

If the dialogue that I had in mind is infeasible at a kernel level then please, 
do close the issue from within the 
MacFUSE area. 

> Why would you compare MacFUSE with the Finder?

I tested to see how "... etc." and "... etc." would react when relatively 
unusual actions were attempted. I knew 
before testing that it could be foolish to open a 16 MB .dmg on an FTPFS, but 
sooner or later we can expect 
users less patient than me to do such things. As a disk image appears 
double-clickable, so some users will 
double-click _without thinking_ about file systems or levels. 

I do understand the differences between MacFUSE and Finder, the levels at which 
they operate, but I confess: 
I'm sometimes not sure where to make suggestions. As you have discovered (for 
yourself) so much about Mac 
OS X I wondered whether there might be more magic ways, in the future, of 
MacFUSE helping things _above_ 
the file system layer. But 

>> Not a priority

Your slides and talks are helping to fill the gaps. 

With the additional knowledge, I'm better prepared to draft some 
MacFusion-oriented documentation. Help 
within the MacFusion application should be ideal, but I have plenty of learning 
to do first. 

Keep up the great work. TIFFs at 
/proc/system/hardware/displays/0 
are inspired!

Thanks
Graham

Original comment by grahampe...@gmail.com on 7 Jun 2007 at 5:29

GoogleCodeExporter commented 8 years ago 
The kernel extension could do some (potentially very stateful and complex, 
therefore undesirable in general) 
things to alleviate some of the funky issues, but the user-visible interfaces, 
particularly the Finder, could still 
behave in unexpected ways because I can't add code to the Finder or the system 
libraries to make them aware of 
file-system-specific special situations.

Original comment by si...@gmail.com on 7 Jun 2007 at 11:46