OT: debatable purpose and value of .DS_Store and ._ files
Graham Perrin
and Finder with non-native file systems.
The HFS+ system is rich.
Systems such as FTPFS, MS-DOS and SSHFS are less rich.
Mac OS and Finder are capable of working with richness:
data, metadata, extended attributes.
If we force our rich data upon a less rich system, then (for example)
Finder will normally ensure that richness is not lost. .DS_Store
and ._ files may be annoying, sometimes troublesome, but they are
proper.
The purpose and value of .DS_Store and ._ files may be off-topic from
MacFUSE and MacFusion, but it's inevitable that we'll be drawn into
the debate.
I'll draft a more calming explanation.
In the meantime, <http://code.google.com/p/macfusion/wiki/SeeAlso>
includes highlights and recommendations.
Kind regards
Graham
xbo...@tillwicks.us
the macFusion team has expressed that they are apples problem, I have
2 questions ( they are kinda far in though ).
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. 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?
Corsec
wrote:
> 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?
Deleting them right after creation is pointless for obvious reasons.
To not create them at all, that is up to the file system or macfuse.
MacFusion it self doesnt implement anything fuse related, and couldnt
solve this problem without actively monitoring the entirety of the
mounted file system for the creation of these files. It is up to the
file systems theme selves to manage the creation of these files. For
example it would be sshfs's job to not create these files if such a
behavior was desired. I can understand why some one might want this in
some circumstances, but as has been stated many times before these
files serve a purpose and should not be discarded recklessly. The
Finder window layout (3 pane, list, sort order, etc) for each folder
is stored in that .DS_Store file. So without them no display
preferences would be maintained, and others might consider that a bug
or defect.
On a side note:
>Like the ._ files with apple, this too is the responsibility of the developers of the browser, in most cases M$.
Microsoft doesnt handle these files at all, it simply ignores them.
They are still there, you can see them by setting the "show hidden
files" option in the explorer window.
Graham Perrin
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
Graham Perrin
Hopefully bringing this thread to a happy conclusion...
experimental use (but not implementation) of
MacFUSE option -o noapplespecial
<http://code.google.com/p/macfusion/issues/detail?id=46>
explain dot underscore ._ files
<http://code.google.com/p/macfusion/issues/detail?id=146#c7>
The debate was predicted around a month ago, I'm glad we waited for
user opinions before drafting Help or documentation on the subject.
The apparent quirks of a few applications (such as Finder and Path
Finder) and the indisputable quirks of some FTP and SSH servers have
been most revealing!
The milestone that Michael (Lead Developer) and I have in mind
for Help on these two subjects is:
* MacFusion 1.3
http://code.google.com/p/macfusion/issues/list?q=label:Milestone&can=2&sort=milestone
Summary
-------
1) Whilst the purpose and value of .DS_Store and ._ files may be off-
topic from MacFusion, we certainly do wish to offer reasonable help on
the subject.
2) The MacFUSE option noapplespecial is much more on topic (but still,
MacFUSE is a separate project). Again, we should offer reasonable help
on the subject. There will certainly be direct reference to advice
from MacFUSE developers.
Kind regards
Graham