Hacking Darwin to remove .DS_Store

[kilowatt]

Personally, I'm hoping apple will come up with something like the BFS (Be's File System). We're allready getting pretty close, with Journaling and such, but if we had Metadata, we could kiss most HFS[+] issues goodbye for ever.

Course, makes you wonder what would happen when you copy those files to another file system.

This is a finder-specific issue, and it wouldn't be too dificult for apple to provide a "Don't store finder view settings on remote volumes" option in the System Preferences. Wouldn't surprise me at all if they did that as a sort of quick-fix.

The entire idea of placing view setting files (preferences, imo) in a world-readable enviroment is very single-user-thinking.

Consider this, lets say you prefer to have icons aranged by importance to your part of a given project. The project resides on a remote server. The project has ten people who all prefer to keep their part of the project at the top of the icon view. Asside from assiging different folders for each member, there is no great solution. Each member will get the same viewing preferences as the previous member.

Really, view preferences should be stored in a sort of cache, similar to how web browsers store cookies, history, and page content. And this should be a client-specific thing. Each client should cache (to a set limit) remote volume view preferences locally. This would save a ton of trouble - 1) you wouldn't have to have those darn windows users complain, 2) you don't have to have your prefs re-written each time another mac user loggs into a cross-platform share, and 3) its more multi-user friendly.

And if they're cached locally, you could easily have them (the .ds files) compressed until a remote volume is mounted.

Lots to think about...

 

[strobe]

BFS supports arbitrary file attributes, but it lacks support for FileIDs which is a deal-breaker.

 

[kilowatt]

But using metadata, couldn't you just add a field for FileID?

 

[strobe]

Originally posted by kilowatt
But using metadata, couldn't you just add a field for FileID?

No.

Basically HFS+ treats the file name as a file attribute and the FileID as the file itself. To find a file by path you look it up in the catalog then get it's ID. Same with folders.

The whole point of the FileID is you can access a file by its ID. Thus when the path changes you can still access the file. Also the path can be considered variable, not constant. (unlike POSIX apps).

 

[kilowatt]

You could allways have a cron job build an HFS+ fileid database, and for those files that are marked as dynamic, they can be indexed. Every night, you would get a fresh list for those legacy apps that rely on file id's. It wouldn't be too hard to build a legacy file handeler.

Bottom line though, if we want to step into the field of high-performance file systems, I think apple will either have to re-invent the wheel, or we'll have to adopt another file system and do without file id's.

Granted, my above fake file-id scheme would be slow and annoying, but... so is classic. File ID's are cool, but I think users and our new unix system can be trusted to place files in semi-logical locations

 

[LordOphidian]

Kilowatt, if we add more metadata to a filesystem, then we would just magnify the problem of having to create hidden files on filesystems that don't support the richness of our metadata. Its not really a HFS/HFS+ specific problem, its a general metadata/non-metadata problem. That said, Be did have some pretty slick ways of getting some of the metadata back that you lost in transition to other fs's.

Also, you can't trust users to do anything the way you want them to. You can hope, but that won't stop them from doing something stupid/harmful.

 

[cabbage]

I think we should start a new polls that says

Hacking Windows to remove thumbs.db

Man those files are really bugging me whenever I copy anything over from my XP box to OS X.

 

[wiz]

how about schedule a task in darwin to delete .DS_Store files automatically from perticular folders!!!

wouldn't that work?

 

[aqsalter]

X-Wizer...

Actually a cron job to delete all .* files from /Volumes every 10 mins would work, but I think to do it properly would require a little bit of work as you would have to be careful not to delete "non-MacOS" files... (ie files that start with ".", but not created by OS X)

You could maybe set up a cron job to run the "Clean SMB mess" on selected volumes (a really good idea), but I don't know how to do this.

"Clean SMB mess" is really fast too... I don't know how it works, but it can clean huge volumes in seconds - whereas the "find / - name .... " method can take _ages_....

 

[kilowatt]

Actually, on a meta data file system, metadata is stored *in* the file. Not as an external file.

But, otoh, I have no idea what would happen as a bfs file is copied over to an NTFS share. 'Guess there are a few posabilities.

 

[jwalk76]

Originally posted by X-wiZeroS
how about schedule a task in darwin to delete .DS_Store files automatically from perticular folders!!!

wouldn't that work?

yes, here is a simple shell script called rmdot that I placed in every users $PATH on my system. each user only has to type rmdot or have a cron job execute rmdot and his/her home directory will be rid of any .DS_Store, .Trashes or ._* files...

find ~ -name '\._*' -exec rm {} \;
find ~ -name '\.DS_Store' -exec rm {} \;
find ~ -name '\.Trashes' -exec rm -Rf {} \; 2> /dev/null

Edit: This happens on my Slackware box, where my webserver is, not on my Mac, where i assume these files are important...

 

[LordOphidian]

Originally posted by kilowatt
Actually, on a meta data file system, metadata is stored *in* the file. Not as an external file.

Actually its stored with the file. That is if the fs supports storing (rich)metadata for files.

But, otoh, I have no idea what would happen as a bfs file is copied over to an NTFS share. 'Guess there are a few posabilities.

Yep, thats the problem. I believe with Be it would just do like OS 9 and let the metadata get striped. With OS X, Apple decided that losing the resource forks (not technically metadata) wasn't an acceptable solution, since OS X supports having many different file systems be local, and trying to use a carbon app on a msdos fs or NTFS would break the app if there wasn't a way to store the data as seperate files. Instead they store it in the ._* files, and the finder stores its metadata in .DS_Store files. Which are the problem we are talking about here. If you added more metadata you would have to expand either the number of files you create, or the scope of the .DS_Store file.

The optimal solution is to provide a pref that lets the user choose if he wants to write out the hidden files if the volume he is writing to is remote. If the volume is local it would probably be best to assume its going to stay local and write out the files to preserve compatablity.

 

[strobe]

This is why I hate UNIX. Everything is a file at a static path. You change the path, things start to break. It's STUPID!

The argument that filesystems shoudln't support metadata because old filesystems do not is ludicrous. I mean ancient UNIX filesystems ony had capital letters in the filename, does that mean no file should have small letters, let alone unicode names?! I mean DOS filesystems are limited to the 8.3 format for crissakes.

I say move FORWARD. Screw filesystems, screw the file metaphor! Files SUCK! All I want is my data, why does it have to be arranged in a contiguous bytestream in a particular format? That isn't how I deal with data within a document.

If we must have a filesystem I won't do it without FileIDs. Without FileIDs all you're left with is the fragile static paths of doom.

As for performance, dealing with static paths has HINDERED my productivity much more than any degredation of peroformance you could surmise is due to not using ext2 or whatever. Let's get back to the human<->computer bottleneck Apple!

 

[aqsalter]

Stobe:

What you are talking about is a filesystem as a database. You query the database for the file you want, it gives you the file. You assign meta data as per your own needs - good examples: iTunes song database, iPhoto photo database.

So I think you should not worry - Apple are on to your concept, but so are MS and Linux... Don't worry!!

 

[strobe]

Stop calling it a file then |-p

 

[LordOphidian]

Originally posted by strobe
This is why I hate UNIX. Everything is a file at a static path. You change the path, things start to break. It's STUPID!

Agreed. Static paths are very useful, and with OS X the way we have it now you have the power of both static POSIX paths and unique file id's.

The argument that filesystems shoudln't support metadata because old filesystems do not is ludicrous. I mean ancient UNIX filesystems ony had capital letters in the filename, does that mean no file should have small letters, let alone unicode names?! I mean DOS filesystems are limited to the 8.3 format for crissakes.

I say move FORWARD. Screw filesystems, screw the file metaphor! Files SUCK! All I want is my data, why does it have to be arranged in a contiguous bytestream in a particular format? That isn't how I deal with data within a document.

Agreed. Here is a good discussion about metadata.

But this is even more tangental to the original question than the original talk on metadata. We are talking about ways of storing metadata, resource forks, etc. on fs's that we know don't support them and can't do anything about.

 

[dirtbag]

I transfer files from my iBook to my 'doze @ work with a USB flash drive.

 

[dirtbag]

Sorry 'bout that...here's my whole message:
I transfer files from my iBook to my 'doze @ work with a USB flash drive. These unix files used to drive me nuts when they appeared on the PC. I set up a search for them in the StartBar and delete them before I even open the disc. Neither the PC nor my Book seem to notice.