Re: network volumes & "dot files" (.DS_store, etc)
- From: Gregory Weston <uce@xxxxxxxxxx>
- Date: Fri, 25 May 2007 21:36:49 -0400
In article <1180121484.947799.242420@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
spacemarine@xxxxxxxxxxxxxx wrote:
On May 25, 6:13 am, Gregory Weston <u...@xxxxxxxxxx> wrote:
ill look into the TinkerTools utility. i see it has a preference for
preventing .DS_store, but im not sure yet if it will do these other
sidecars.
It better not. The "other" sidecars are the file system metadata and
potentially resource fork of the file(s) you're transferring. They're
created when the file system in use doesn't support the additional
information directly (anything except AFP) and deleting them will be
anywhere between inconvenient and outright crippling, for no gain other
than aesthetics.
im sorry -- how are these files critical to a windows operating
system?
I didn't say they were critical to a windows operating system. They
_may_ be critical to the Mac program that comes along later and tries to
read the file.
if im moving files from a mac, to a win file server, why would windows
require a mac-os resource fork file? the content i care about is in
the binary of the files being moved. i dont see how that can change by
removal of metadata.
Where the information you care about depends on the file type. Granted,
for any commodity file type you'll run across, any information that does
happen to be in the resource fork can be lost without a problem. But it
would be a bad idea to just do it as a matter of habit or policy unless
you have great confidence that none of the Mac users on the network are
ever going to put a file out there where the resource fork _is_
significant.
its more than aesthetics, its good file management. having a billion
files that do *nothing* for the remote os, sitting on the remote os,
is frowned upon.
So once the file goes over there it's never going to accessed by the
client OS again? I missed where you said that before.
sidenote... perhaps obvious is my newness to the mac os. why does it
place metadata in a sidecar, rather than embed it w/i the file's
binary stream?
As I said, it's (at least in part) _file_system_ metadata. It's
ancillary information about the file as an entity and controlled by the
file system. It's not ancillary information about the file content
controlled by the editor for that content.
The other possible contents of those files are a stream of information
called the resource fork. It's not embedded within the primary stream
because being a separate manipulable stream was fairly fundamental to
the concept (because, for example, it might actually corrupt the primary
stream if it's present even a simple ASCII text file can have a resource
fork). You'll notice that the idea of multiple data streams tied to a
single directory entry has been becoming more popular, rather than less.
G
.
- References:
- network volumes & "dot files" (.DS_store, etc)
- From: spacemarine
- Re: network volumes & "dot files" (.DS_store, etc)
- From: spacemarine
- Re: network volumes & "dot files" (.DS_store, etc)
- From: Gregory Weston
- Re: network volumes & "dot files" (.DS_store, etc)
- From: spacemarine
- network volumes & "dot files" (.DS_store, etc)
- Prev by Date: Re: network volumes & "dot files" (.DS_store, etc)
- Next by Date: Re: newbie - scripts, volume mounting
- Previous by thread: Re: network volumes & "dot files" (.DS_store, etc)
- Next by thread: Do you give admin privileges to your day-to-day acct?
- Index(es):
Relevant Pages
|
