Invisible files - DS_Store

Lazzo

Lazzo

Registered
It appears that something in OS 10.1.3 (????) creates an invisible file named '.DS_Store' which I've apparently contains just about all your hard drive details (folder names, document names, maybe even passwords and so on) and scatters duplicates of it throughout the hard drive. No problem in itself, but when using ftp to upload files and folders to a web space, this invisible file naturally goes with them. This could be nasty from a security point of view.

A related problem turns up when you try to delete the files/folders from the web space - you can't, you'll get an error 550 (permissions) and possibly a line saying 'directory not empty'. This means e-mailing or 'phoning your ISP tech support to ask them to get rid these little offenders. Which, unless you are a paid-up reseller, can be a painful task.

I have found no information about what .DS_Store does or why, but using FileBuddy or similar to make them visible then trashing them doesn't *SEEM* to do any harm - although I have only been brave enough to delete them from clients' folders before uploading, not from anywhere else on the system.
Does anybody else have any information about these files?
 
Each .DS_Store file contains information about the folder that it lives in, things like the position of the folder's window, its view and so forth. They aren't "duplicates." When you're booted into 9 they become visible, which sucks, but you can delete them without any ill effect if looking at them annoys you.
 
Thanks, Slur. Mind at rest.
I didn't mind looking at 'em - it's suddenly discovering undeletable folders on the clients' servers that bugged me - and the client!

Cheers
 
Yeah, this is a wonderful hold-over from the *nix world. Since *nix is usually filesystem-neutral, there had to be a better way to store this information. Under OS 9, it was a hidden file, but there isn't a filesystem-neutral way of doing a hidden file bit. So, any file starting with '.' is considered hidden.

If you look in your user folder, you should find a few '.' files as well, especially if you use the terminal.

The result is that other OSes that aren't filesystem-neutral and don't hide files begining with '.' suddenly get these files in their face. Fun.
 
Oh, I've got dozens of 'em! Taking your comments on board, I've just realised that these files must be what a printer and a client have been on about the last few weeks. They were worried, I told them to trash them as I thought they were the desktop files that always appear on CDs. At least they're harmless in that respect.
This morning (as you know, public holidays don't exist for the self-employed) I spent another jolly half-hour clearing them out of a website before spending a measly three minutes uploading it, to prevent 'folder-lock' on the server. If there's an Applescript or something to do this it would be helpful? I haven't had time to investigate Applescript Studio yet. Obviously I'm not the only sufferer.

Thanks.
 
What's interesting to me is that, under Mac OS 9 you can make any file invisible by setting its "invisible bit." I'm not sure why this bit isn't set for the .DS_Store and other files that would be better left unseen. Must be some kind of compatibility issue....
 
Probably just a cockup! Most OSX invisibles show up in Classic save and open dialogues as well. Maybe Apple aren't interested in reverse engineering, I personally don't blame them for that. I look to the future too.
I've been using Macs since 1987 and never been forced to examine the deeper system workings like this before. I'm an Old Fart nowadays but my dormant mind has been slightly awoken by OSX.

PS to everybody: If I post anything that appears daft, juvenile etc. hopefully it's because I've never posted to a forum before this week. Well, I hope I'm not daft. I shall attempt to keep future posts 'mostly' relevant as I see this as a helpful place. And I was never a chatty person blah blah blah...

Cheers
 
What's interesting to me is that, under Mac OS 9 you can make any file invisible by setting its "invisible bit." I'm not sure why this bit isn't set for the .DS_Store and other files that would be better left unseen. Must be some kind of compatibility issue....
Click to expand...

As I already posted, *nix-based sytems are filesystem-neutral. Many filesystems don't have the concept of the invisible bit that HFS/HFS+ has. So, to remain filesystem-neutral, OS X uses '.' just like other *nix systems. This is so that you can theoretically install Linux on ext2, ext3, HFS, FAT32, rockridge or others without problems. MacOS X *CAN* boot off of a UDF partition, and has support for MS-DOS partitions, and requires the full support for window positions/etc stored in .DS_Store, so it couldn't just set an invisible bit on files on those partitions.
 
I propose that on systems that do support the invisible bit, it should be set on dot-files. Although certain parts of the system are certainly filesystem-neutral, the filesystem driver code itself certainly isn't. Just as resource forks on flat filesystems are stored in dot-underscore files, the attributes of dot-files can and probably should be tailored to the capabilities of the filesystem.
 
Then you complicate the API for a filesystem kext by adding all these un-needed calls that do nothing but waste CPU time on the majority of filesystems. There is no call to 'set this file invisible' under Cocoa, or even in the kext. It is kluged in Carbon, but that is just that, kludged.
 
There are a host of files and folders that Mac OS X sets "invisible" via the "V" attribute bit.

% GetFileInfo ~/Documents/.DS_Store
file: "~/Documents/.DS_Store"
type: ""
creator: ""
attributes: aVbstclinmed
created: 11/15/2001 00:12:13
modified: 11/15/2001 00:12:13

Use a file tool such as SNAX to rename one of the invisible .DS_Store files. You will notice that the file's "invisible" bit remains set. Or try this:

% touch my_file
% SetFile -a V my_file

Voila, you've made an invisible file.

The only annoying thing is that Mac OS X uses a different attribute to mark invisibility than Mac OS 9 does. Apple wouldn't have to change the interfaces or add more calls to the filesystem kext, but simply add the necessary code to set the visibility attribute bit for 9 at the same time as for X. Such a change would not impact the performance of the filesystem or complicate the APIs at all. It would simply correct a silly oversight.
 
You must log in or register to reply here.
Back
Top