
.Trashes, .fseventsd, and .Spotlight-V100 - pmoriarty
http://blog.hostilefork.com/trashes-fseventsd-and-spotlight-v100/
======
derefr
A few little arguments _in favor of_ this practice:

1\. You plug a USB device into one Mac. It asks you if you want to use it for
Time Machine. You say no. Now, no other Mac will ask you this question
again—because the preference has been stored on the drive, instead of on the
computer.

2\. You create a folder with an app you've written in it, and customize it
with a cute "drag [this] onto [shortcut to Applications folder]" background,
centering the icons on the background positions and sizing the window to
perfectly fit the representation. You then copy this folder to another Mac (or
any equivalent process, such as converting it into a DMG disk image and having
someone download it.) They see exactly what you saw.

3\. You keep an external hard disk that you frequently move back-and-forth
between two Macs. The first time you plugged it into one of the Macs, it was
indexed. Each time you modify it on either Mac, that index gets updated. The
most recently created files are the most likely to be the ones you'll want to
find through Spotlight when you plug the disk into the other Mac—but if the
index was machine-local rather than disk-local, the new Mac wouldn't know
about the new files yet, and would have to finish re-indexing to find them.
(This is, of course, what happens when you modify the disk on a Windows
computer, and it sucks. We really need a "metadata index API" to start being
an expected offering of a filesystem, such that all OSes interacting with the
filesystem can read and update it!)

On the other hand, Windows' Thumbs.db is exactly the sort of thing you _don
't_ want cached on the media. It'd be a great innovation if, say, cameras
could pre-generate Thumbs.db files so Windows could immediately show the user
what was on an SD card the first time it got plugged in... but cameras don't,
because Thumbs.db is a random proprietary format. So, instead, it's only
useful in the same situation that the Spotlight index is: moving a drive full
of photos back and forth between two computers. Which might have separate
screen DPI, and thus be set to show different thumbnails, meaning new
thumbnails will get generated anyway.

~~~
ploxiln
Or, OS X could wait until the appropriate time to offer you the option of
messing with your disk.

1\. Don't ask about using the disk for Time Machine. When the user goes to
Time Machine because they want to use Time Machine, then have a button in the
sidebar "Use drive blah for Time Machine" for any non-time-machine external
drives present.

2\. Have a button at the top of a finder window in which icons have been re-
arranged saying "preserve layout in this folder" (which you only have to click
the first time, of course it remembers along with the layout). (Also, make it
more convenient to default all folders/finders to list-with-details view, for
people who have any idea what they're doing.)

3\. When the user opens Spotlight, have a button in the sidebar "index this
drive for Spotlight" for any un-indexed drives present.

In all these cases, it's still super duper easy to use all these things,
without _always_ bothering people who don't want these things.

~~~
PinguTS
That is this kind of thinking of engineers vs. regular user.

You know why Windows users are so prone to viruses and such? Because they
learned to click "OK". They learned it, because they always got the
question/offer if they want to proceed or not. But a regular user don't
understand those technical details and you know, they don't _want_ to
understand those details. So we learned them to click "OK".

The best UX for the regular user is any UI where regular users have less
choices of technical details.

I said that already the other day: as an engineer myself, I were chatting with
another engineer about a product they have done (device integrated into a car
for special purposes). I said to him, that something feels wrong with the
interface. Yes, all the required information is present. Yes, probably I
myself would have designed the UI the same way. But over the time I've got
some sense in terms of UX, which a product makes it compelling or just doing
its job.

The same you see with smart home. For how long there are HVAC controls out in
the field by Honeywell and others? The better one are all programmable in all
regards. But only Nest, which removed a lot from the interface made the big
wave.

~~~
ploxiln
That's not a good argument against my proposal. How is

Want to use this drive for Time Machine? [OK]

better than going into the time machine app / prefpane / whatever, and seeing
[use drive WD-BOOK for time machine] on the side, non-modal? so people who
don't know what they're doing don't have to click or even see anything?

UI/UX designers do a lot of really stupid stuff in the name of making things
"simple" and "easy". Engineers who think they're more of a people person and
know some UI/UX probably do it even more. Give up the gimmicks, the ridiculous
space between elements. The material design, the flat-aqua design, it's all
crap.

I've seen "regular users" fail to use all these things, and need my help find
a way through the increasingly hidden and opaque interfaces to what they're
trying to do. Usually because things that are supposed to "just work" instead
"just don't work" and there's no way to fix it. Except for me. So interfaces
designed for me would probably not be a bad idea ;)

~~~
mcmillion
Most of the users I know wouldn't know where to go to set up a Time Machine
drive. The fact that it prompts them flat out is how they even got it set up
in the first place.

------
Doctor_Fegg
I'd be more inclined to berate Apple for this were it not for the amount of
crap that Unix-style tools dump in my home directory.

I count 50 .-prefixed files or directories at present, some of which is from
Mac developers who should know better (hello, Adobe, Dropbox), some is
cryptically-named gunk from other tools (.vegas, .jmf), some various command
line histories (bash, fcsh, mysql, psql, pry, sqlite, irb), and so on.

OS X is nicer than traditional Unix behaviour here - it puts it all in a well-
organised ~/Library directory.

~~~
rat87
On Linux things should go in xdg dirs ~/.config ~/.local and ~/.cache instead
of ~ but a lot of old unix software and sadly a decent amount of new
software(even guis) don't follow the standard.

------
nkantar
This accomplished two things:

1\. I now know a few things I've wondered for a long time.

2\. I have just been reminded of how little I really know, even about devices
I use for most of my waking hours.

------
piersadrian
for the love of christ, it's OS X, not OS/X

~~~
yellowapple
I want to see someone come out with an OS/2 skin of sorts for OS X, just to
make everyone in the world that much more confused.

------
angelortega
So that .Spotlight-V100 store some kind of index, probably binary. I presume
that any Mac reads it on any arbitrary USB drive it's plugged in (or, at
least, when a search is triggered). By creating a specially-crafted, corrupted
index I see a channel for denial of service attacks.

~~~
dchest
You can probably still abuse NSDictionary, causing HashDoS
([https://gist.github.com/dchest/4467707](https://gist.github.com/dchest/4467707)).
I did it with QuickLook a few years ago; don't know if they replaced a hash
function there.

------
userbinator
_Hopefully users will push back; demanding to be given more options, and more
control. We 've gotten to a point where the role technology plays in our lives
is too integral to keep letting that control slip away, one "harmless" feature
at a time._

Amen to that. Unfortunately it seems the trend is towards hiding the
filesystem/concept of files completely from the user and replacing it with
app-specific isolated storage in a proprietary format, which is even worse
than unsolicited filesystem modifications. (On the other hand, it could be
argued that these modifications would become even less noticeable in such a
system... which is good or bad depending on who you ask. I'm firmly on the
latter side.)

A physical write-protect is something all removable storage should have.

------
konsumer
I do this if I forget to add .DS_Store to .gitignore when working with git
repos: find . -name .*DS_Store -delete

~~~
manicdee

        git config --global core.excludesfile ~/.config/git/ignore
    
        cat >> ~/.config/git/ignore
        .DS_Store
        .AppleDouble
        .LSOverride
        .AppleDB
        .AppleDesktop
        .apdisk
        .fseventsd
        .Trashes
        .Spotlight-V100
        ._*
        Icon
        Network Trash Folder
        Temporary Items
        Icon

~~~
xorcist
Why not .* ?

I can't think of a good reason to commit hidden files.

------
chiph
It seems to me, that if I insert a removable media that is formatted with one
of the FAT filesystem variants, that I probably don't want those hidden files
& folders created. As it's a sign that the ultimate destination probably isn't
another Mac.

------
pippy
It is annoying when copying a movie to a USB, and having to empty the entire
trash bin to fit it on the USB stick. I guess it does enforce you to be a bit
cleaner.

I don't really care about .DS_store etc as they're hidden, and thumbs.db is
just as bad.

~~~
simlevesque
> I don't really care about .DS_store etc as they're hidden

They ain't if you are on Windows.

~~~
derefr
That's really just silliness on the part of Apple; if they're creating
dotfiles on a FAT32/NTFS/ExtFS disk, they should be setting the Hidden
attribute for those same files. This is what e.g. Samba does automatically for
network-attached FAT/NTFS folders on OSX/Linux clients, if I recall.

~~~
manicdee
There was a patch submitted to the Darwin project to do this:

Https://lists.apple.com/archives/Darwin-kernel/2004/Jul/msg00120.html

I don't think it ever got reviewed though.

------
nathanstaines
Eject for Windows ([http://www011.upp.so-
net.ne.jp/decafish/EjectForWindows/Ejec...](http://www011.upp.so-
net.ne.jp/decafish/EjectForWindows/EjectForWindowsE.html))

------
0x0
Before OSX 10.10.2, apparently there was a "heartbleed" style info leak in
spotlight where it "may save unexpected information to an external hard
drive", according to [http://support.apple.com/en-
us/HT204244](http://support.apple.com/en-us/HT204244) (CVE-2014-8832).
Probably related to this report:
[https://www.f-secure.com/weblog/archives/00002752.html](https://www.f-secure.com/weblog/archives/00002752.html)

------
wampus
What happens when the drive is shared among Macs? Why isn't this a vector for
exploitation?

~~~
__david__
Well, if you find a buffer overflow that can lead to code execution in
spotlight (mds) or fseventsd then it very well could be a vector. Assuming no
bugs in those (hah), then I'm not sure what you could exploit…

------
blueskin_
Never understood why they do this. Surely they should keep junk off removable
drives, as they are the _most_ likely to be used in other systems including
ones that don't hide data from the user.

------
nfoz
It's just nonsense that this metadata would be dropped as files scattered
across the filesystem, rather than simply held in a single location on the
host machine. They're a fragment of the OS, not of each directory.

~~~
PinguTS
Which would mean that those meta data is only available on this host and not
anywhere.

The problem is the short coming of those file systems not to allow to store
arbitrary meta data to any file.

~~~
nfoz
That's exactly what I want though. "Folder display preferences" are a thing
that pertain to exactly one instance of one operating system. If I want to
share "folder displays" to a different computer (which seems rather
unnecessary), that seems like an explicit action I might take between the two
computers, and all that metadata should be a single bundled file that is
transferred between machines. Not per-directory metadata that is bundled into
my filesystem everywhere.

