Two questions for MacFUSE developers:
1) Effect of noapplespecial Please, is the effect of -o noapplespecial limited to reading from a volume for which the option is set? Or, is noapplespecial intended to suppress writing as well as reading of ._ and .DS_Store files? (The answer is not as obvious as one might imagine; AFAIK if Finder can't read a ._ file on a file system on which ._ is required, then Finder may not successfully copy the file to which the ._ counterpart relates.) 2) Advisability of noapplespecial My sense at the moment is that noapplespecial should be discouraged, to the same degree (but for different reasons) that allow_root is discouraged. Thoughts? I appreciate that noapplespecial is experimental but we're considering user opinions of ._ and .DS_Store files ... ========== Background ========== 1) Re Finder and .DS_Store files, Apple offer advice <http://docs.info.apple.com/article.html?artnum=301711> but >> Please note that disabling the creation of .DS_Store files on >> remote file servers can cause unexpected behavior in the Finder 2) Unless I'm missing something, Apple offer no way to suppress ._ dot underscore files. I understand why they should not be suppressed. 3) TinkerTool appears to observe (1) but does not work around (2). 4) As there are often good reasons for the presence of ._ and .DS_Store files I tend towards the Apple way, I recommend neither removal nor suppression . 5) For environments in which ._ or .DS_Store are a problem, there are various solutions. WinFSCleanser <http://home.comcast.net/~themacgeek/> seems to work fine with volumes mounted via MacFUSE/SSHFS/MacFusion and the developer makes good use of log files, see for example <http://pastie.textmate.org/68528>. ========================================= Brief experiments with noapplespecial and Finder, Path Finder and NeoOffice ========================================= <http://groups.google.com/group/MacFusion-devel/browse_frm/thread/ f0d6fd9d64e2c6a1> ================== Related discussion ================== At <http://groups.google.com/group/MacFusion-devel/browse_frm/thread/ 67b3e3e141cdc162>: > ... I'll draft a more calming explanation ... I'm taking in <http://www.osxbook.com/book/bonus/chapter11/macfuse/> and the like before finalising my thoughts on all of this. ## Off-list, I wrote: > First and foremost, > >> Re Finder and ._ files, Apple offer >> NO way to suppress dot underscore files. > > I do understand your frustration. > > Questions re: Mac OS and Finder are best addressed to Apple. > > For discussion of > MacFUSE development and advanced usage issues -- including the > sshfs-static binary, and the noapplespecial option for MacFUSE: > <http://groups.google.com/group/macfuse-devel/about> > > For discussion of the MacFusion GUI: > <http://groups.google.com/group/MacFusion-devel/about> > > At <http://code.google.com/p/macfusion/wiki/Explanations> > we should make clearer the distinctions. Done. > When I'm less busy, I will: > > a) offer more specific comments regarding your examples Done, off-list. > b) draft more adequate explanations regarding ._ Ongoing. ## Later in <http://groups.google.com/group/MacFusion-devel/browse_frm/ thread/67b3e3e141cdc162>: > As far as the _ ( dot underscore ) files are concerned and considering > the macFusion team has expressed that they are apples problem, > I have 2 questions ( they are kinda far in though ). I don't suggest that ._ files are a problem but I do recognise that their proper use can be problematic for some users. > First, if that is your stance and I did not intemperate that > incorrectly, I have something to say. I have been a web developer for > over 8 years and in that time there are countless work-a-rounds which > I had to implement in my code ( and I'm sure 99% of web developers as > well ) to compensate for an action of a browser that didn't behave as > expected. Like the ._ files with apple, this too is the > responsibility of the developers of the browser, in most cases M$. > So, since we can all pretty much predict, apple will not provide any > solution to problems created by these ._ files when being used on > unsupported filesystem types. FWIW I don't share this prediction, in my experience Apple are far more co-operative than Microsoft. I have managed AppleShare and other file servers since the mid-1990s,long before AppleShare IP, long before Mac OS X, so I have watched the ._ and .DS_Store debates over many years with interest but I confess: it's only in the past two weeks that my own selfish interests have led me to figure out some of what's *truly* going on with ._ files. Re <http://docs.info.apple.com/article.html?artnum=106510> and the like, people most often think of ._ files as synonymous with resource forks; but ._ has purpose beyond this. For example: a Finder copy routine may require a ._ write at the destination, at some point during the copy -- even when the source file has no resource fork. For those of you with an interest in the history: the ._ in that situation includes the strings 'brok' and 'MACS' to denote a file that is busy, a file that is being created by Finder. Ah, misty coloured memories of the jack-in-the box ... <http://developer.apple.com/documentation/mac/resedit/resedit-2.html>! I'm still curious, still learning :-) > Therefore, the fact that macFuse and > macFusion are ultimately responsible for the management of ._ > and .DS_Store files and any other file management on non-apple > supported file systems that macFuse provides here are my 2 questions. > > Question 1: Since I have given examples above of why Apple is NOT > responsible for the management of ._ and .DS_Store files on > UNSUPPORTED file systems then it is up to someone else to take that > responsibility upon themselves. So, whose responsibility is it, > macFuse's or macFusions? > > Question 2: If which project should be responsible cannot be decided, > why can't macFusion ( in future releases of course ) offer user > selectable options to enable "management" of ._ files on mount types > such as sshfs and ftpfs ( where they are the biggest nuisance ), and > by "management" I mean delete them immediately after they are created? Files such as .DS_Store can be a nuisance with protocols/systems other than sshfs and ftpfs - including but not limited to SMB/CIFS and WebDAV -- but as noted at <http://docs.info.apple.com/article.html?artnum=300421> blocking (or removing) such files: >> can degrade the experience for ... users who are working in the >> Finder. Similar to a read-only volume, client metadata for >> folders on mounted ... volumes, such as icon positions and view >> options, will not be persistent from one login to the next. Removing or blocking ._ files can be degrading in other ways. I'm not devaluing solutions such as WinFSCleanser. Rather: I caution against configurations that might -- in any situation -- lead to unexpected loss of data. (Example: a lab administrator might be tempted to set the noapplespecial option, or something comparable, for the benefit of service administrators -- but this could be degrading for end users.) My esteem for Cyberduck fell after I discovered that it had silently, with no warning, stripped valuable data from many of my files. Kind regards Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "macfuse-devel" group. To post to this group, send email to macfuse-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/macfuse-devel?hl=en -~----------~----~----~----~------~----~------~--~---
