[chingwei]

Hi all,

I am using my PowerMac OS X 10.1 on a Windows network. I like the fact that I can use the Go->Connect to Server to connect to SMB/CIFS shares, to access Windows shared folders etc directly from OS X...

However, I find it really annoying/unacceptable that OS X leaves all the .ds_store, ._filename, and .trash etc "hidden" files all over the place. Especially the .ds_store files, which just get dropped into every folder you browse into.

I know these are harmless to delete, and OS X Finder needs them to retain settings etc. But I really want to find a way to stop this from happening. I really don't care if Finder loses it's view preferences etc...It just confuses everyone else on the network, and it might accidentally end up on some materials that we send to our customers. And I don't consider changing my Windows Explorer settings to not show hidden files a solution, since the files are still there, and I can't control other people's PCs.

I know that if you use Dave, you do not have this problem. Here's a quote from MacWindows:

Other OS X file services such as NFS, Sharity or Apple's own SMB must rely on a "compatibility layer" to provide the special needs of Macintosh files. This "compatibility layer" actually makes files services that use it LESS compatible with Microsoft's Services for Macintosh (and DAVE). You might also notice that it leaves lots of extra files laying around on your server. A file named "OurLogo.jpg" will also have an extra file named "._OurLogo.jpg" in the same directory. These extra files have been known to increase the anxiety level of Windows system administrators. Macintosh users really don't want to make PC administrators anxious.

My question is this: Before I go out and spend $149 on Dave, I want to know if the new OS X 10.2 Jaguar will solve this problem too. Apple mentions greater compatility and interoperability with Windows networks in their new OS (see here), but don't mention specifically about the hidden files problem.

I know many of you are playing with the prerelease builds of Jaguar. Can you please help me out? I am probably going to buy Jaguar no matter what. I want to know if I would be wasting my money by spending $149 on Dave now?

Are there any other solutions (other than Dave, or possibly Jaguar) to my problem?

Thanks!
-Ching-Wei

[pat++]

This is fixed under Jaguar. So you can go and buy 10.2
No need to buy Dave.

[karbon]

When I tried copying a file to my WinXP in 10.2, it still created an additional ._filename file there.

Extremely annoying, and not acceptable. Is that AppleDouble or something? Why would I need that on a SMB volume? And why is there no option to turn this **** of? Anyone know? Some settings in /etc/smb.conf maybe?

[Eug]

Considering these are all likely cross platform files anyway, it'd be nice to turn off all this stuff. It's not as if we need all the extra info anyway. I delete all this stuff whenever I see it.

[keston]

But windows users get a bit edgy seeing these files. The PC admin does not like seeing this breadcrumbs on the company's production server Virus is teh first thing that starts poping into thier heads

[CharlesS]

If OS X did this the way OS 9 used to, having all the special files grouped together in a folder named something like "HFS+ Special Info" at the root of the disk instead of being littered all over the drive, it would probably make sysadmins happier...

[mrtew]

This reminds me of the resource fork that Windows users always get when you email them a picture that looks like a seperate file to them that they can't open. Apple has really GOT to get a freaking clue about stuff like this. Apple's have to look to the world like normal computers, not freaky machines that are constantly generating garbage files everywhere that Mac users don't even know about.

When I look at my invisible files on my own computer I am sickened by the pile of carp at my root level. Making them invisible just makes me feel like there dirt under my carpet and I still see half of them on other partitions. Can't these be in a folder in the system folder? Far from being simple to use, all this invisible file stuff makes Macs look impossible to understand.

Apple, get a CLUE!

[chingwei]

Glad I'm not the only one who thinks this is a huge problem...there isn't much talk about it around the web (as far as a google search takes me).

So now I've heard (from this thread and elsewhere) conflicting remarks that 10.2 does solve this problem, 10.2 doesn't solve this problem, AND that Dave actually doesn't solve this problem.

Which is true? If Dave works, I will probably just go with that...

-Ching-Wei

[keston]

The same thing happens when using DAVE. The MAC OS is the culprit.

[chingwei]

pat++ and karbon: you have opposing views on 10.2 and this hidden file business. Can you tell us which builds each of you are using?

Thanks!

-Ching-Wei

[ZnU]

Originally posted by mrtew:

When I look at my invisible files on my own computer I am sickened by the pile of carp at my root level. Making them invisible just makes me feel like there dirt under my carpet and I still see half of them on other partitions. Can't these be in a folder in the system folder? Far from being simple to use, all this invisible file stuff makes Macs look impossible to understand.

There's no fundamental technical reason why this stuff couldn't be somewhere else (inside /System for instance, and named with nice understandable names) but it would provide essentially no benefit (since the user never had to mess with it anyway) and it would break most Unix programs.

Don't worry about this making the Mac look bad; it can't possibly bother Windows users. In Windows the entire file system is so cryptic and ugly that MS had to cover it up with the Start menu. Most Windows users, in my experience, almost never actually look at the contents of their hard drives.

[billybob]

Yah, this problem is so irritating, I can't believe apple hasn't done anything about it. I have 6c87 but haven't tried SMB yet. I'm booted into 10.1.5 now and doing stuff so I cant test it right now. I'm getting 6c115 right now and when it finishes i'll log into my girlfriends PC (mines out of commission right now ) and see what happens.

[someone_else]

All right, some of you guys need to get a clue. The reason for these files is given in the OP's post and yet he still posted!

These files are CRITICAL in some cases to the proper operation of your Mac. .DS_Store aside, all of the other ._ files are AppleDouble encoded files that hold the resource fork and HFS meta info for that file (type/create, Finder bits, etc). If those files were not there, any non-bundled Carbon app would fail, and any data file with a resource fork would be corrupted.

Now you may say. "Well I don't run non-bundled Carbon apps from my SMB/NFS/whatever share." Well guess what; Apple doesn't know that. Apple is playing it safe and making sure they don't corrupt files with a resource fork that other people may copy to their shares.

As for bitching about hidden files. That is a joke. Windows itself has so many hidden, special, and system files littered all over the place that its users don't have a right to complain.

[phrenzy]

And the Apple apologists come out again defending the OS leaving crap files all over servers.

How about an option:

Don't leave those stupid resource forks on the server !!!

You see, I like to use BBEdit to edit lots of stuff at my job (video game development)

Now, we have all kinds of automated batch files which copy things like *.txt into other servers to build the final DVD for the game...

Everytime I use my Mac there are shitloads of _blabla.txt files all over.

WTF - Why can't I just turn this off?

I just want the OS to use the FILE EXTENSIONS to ID the file types when they are stored on Windows Servers..

Isn't that how Windows works?!?!

It's like, they are giving priority to the HFS+ system even though you are connected to a WINDOWS server.

All I'm asking for is an OPTION - maybe, say, do NOT write resource forks for DOCUMENTS - but anything .APP can have them.

Interestingly, when you use the Terminal and use things like PICO or Vim to edit things - they DO NOT leave this crap behind!!! So the Terminal actually behaves BETTER than the OS in this respect!

There is no defense for this crap - and anyone trying to justify it is just grasping at straws.

[someone_else]

Originally posted by phrenzy:
And the Apple apologists come out again defending the OS leaving crap files all over servers.

How about an option:

Don't leave those stupid resource forks on the server !!!

You see, I like to use BBEdit to edit lots of stuff at my job (video game development)

Now, we have all kinds of automated batch files which copy things like *.txt into other servers to build the final DVD for the game...

Everytime I use my Mac there are shitloads of _blabla.txt files all over.

WTF - Why can't I just turn this off?

I just want the OS to use the FILE EXTENSIONS to ID the file types when they are stored on Windows Servers..

Isn't that how Windows works?!?!

It's like, they are giving priority to the HFS+ system even though you are connected to a WINDOWS server.

All I'm asking for is an OPTION - maybe, say, do NOT write resource forks for DOCUMENTS - but anything .APP can have them.

Interestingly, when you use the Terminal and use things like PICO or Vim to edit things - they DO NOT leave this crap behind!!! So the Terminal actually behaves BETTER than the OS in this respect!

There is no defense for this crap - and anyone trying to justify it is just grasping at straws.

I'm not an Apple apoligist. There are things wrong with Apple (year old hardware tech) and OSX. However, the ._ files is not one of the things that are wrong.

First, checking for .APP will not work, neither will checking for a bundle plist. Not all apps are bundled. Those that aren't will not have .APP. BBEdit is a perfect example. It is not bundled and therefore does not have a .APP extension.

As for the Terminal doing the "correct" thing, this is because the BSD layer (not really Terminal) does not go through the Carbon layer. The Carbon layer knows about reasource forks and HFS meta info.. The BSD layer does not.

For instance, if you try to copy a file with a resource fork (App or not) from your local disk to another local disk from the BSD layer it will happily strip the resource fork (corrupting the file in the process) even in if both disks are HFS+.

Apple is doing the right thing here. It is better to piss off a few users than to corrupt the majority's files and piss them off.

If you want to avoid the ._ files, copy from the command line. It would also be very simple to whip up a quick Cocoa app to do Drag and Drop copying (drag a folder/file to copy, select a destination, and go). Since Cocoa doesn't go through Carbon either, you wouldn't get the ._ files.

[CharlesS]

Originally posted by ZnU:


There's no fundamental technical reason why this stuff couldn't be somewhere else (inside /System for instance, and named with nice understandable names) but it would provide essentially no benefit (since the user never had to mess with it anyway) and it would break most Unix programs.

It would provide the benefit of being better organized.

It wouldn't break any UNIX programs at all if you left symlinks to the various directories on the root level.

Don't worry about this making the Mac look bad; it can't possibly bother Windows users. In Windows the entire file system is so cryptic and ugly that MS had to cover it up with the Start menu. Most Windows users, in my experience, almost never actually look at the contents of their hard drives.

The fact that the Mac OS does something badly is not excused by the fact that Windows does it worse.

[CharlesS]

How about an option to add the ._appledouble file if a file has a resource fork, but not for other data? Then files at least wouldn't be crippled, and there'd be a lot less of the ._files lying around.

[shortcipher]

The Mac OS add the ._fiulename files even for files which do not have resource forks!

I regularly work on html files stored on our webservers, i use ftp to access these files, resource forks are not needed and not copied and the lack of them does not damage the files themselves.

Apparently FTP in the finder is implemented under 10.2, perhaps this is the solution many of us are looking for? (for website access I mean)

The only other reason I have ever used smb was when connecting to our NT4 server crashed the finder (using Appletalk), now I gather this problem really has been fixed with 10.2.

I agree though, this should be an option for those people who know what they are doing with their files.

[ZnU]



Originally posted by CharlesS:

It would provide the benefit of being better organized.

What's the benefit in organizing something the user almost never sees?

It wouldn't break any UNIX programs at all if you left symlinks to the various directories on the root level.

That creates just as much of a mess as having the real files there, of course.

The fact that the Mac OS does something badly is not excused by the fact that Windows does it worse.

The previous poster seemed to think that this was somehow making the Mac look difficult to use. It's not going to make the Mac look difficult to Windows users, because they're used to worse.

[chingwei]

My main gripe is about the .ds_store file that is left in every single folder that I browse through SMB, whether I read/write files there or not!

I understand if Mac OS is writing a file to a network file server that it would have to maintain it's own file settings and etc, since the file was written by a Mac. I have no problems with keeping track of any files I've created using my Mac, on an SMB volume, and deleting the appropriate ._filename files, that is understandable and manageable (although irritating).

But if I am just browsing an SMB network, clicking on down several levels of directories/folders, and maybe click on a PDF or something just to read (not to modify or save), or even if I don't read anything, I am left with one .ds_store file in every directory level. Which is a b*itch to delete! You basically have to remember every single folder you may have browsed your way into, and delete the .ds_store file there.

From what I understand, the .ds_store file helps the Mac Finder keep it's view settings for that folder, e.g. viewing as a list, or as icons, etc...Why can't that be stored in a central location on the Mac system itself? It's a totally backward method of keeping these folder settings, and seems to have been created based on the assumption that the only folders that the Mac Finder would ever see would be local discs on the same machine. .ds_store files makes no sense when the same folder can be viewed from multiple machines, and when the disc doesn't even belong to you!

And regarding Windows hidden files, can you please explain what you are talking about? I admit there are hidden files galore on the system disc (on the root C, and in the Windows System directory...mainly in the main system or program areas). But not on purely data folders, which is what we have on our network. People just copy files to the network, we don't install any programs or etc, I don't see any hidden files in these shared folders. And all the view settings of the folders for Windows Explorer are presumably saved somewhere in the OS itself, and not in the folders themselves, so different people accessing the shared folders from different machines can have their own view settings.

And before we take the Windows bashing any further, remember that SMB shared folders are not Windows specific, Linux and other OSes (including OS X!) can share stuff using the SMB protocol too! I'm sure that if you were connected to a Linux shared folder via SMB from OS X, you would leave all those crumbs (.ds_store, ._filename) around too!

Can we get a confirmation on whether 10.2 solves this problem or not?

Thanks!
-Ching-Wei

[Lew]

It still leaves dotfiles for some files, but at least it now sets Windows' hidden bit on the files, so most end-users won't see them. Same with the .ds_store file.

[someone_else]

Originally posted by chingwei:

But if I am just browsing an SMB network, clicking on down several levels of directories/folders, and maybe click on a PDF or something just to read (not to modify or save), or even if I don't read anything, I am left with one .ds_store file in every directory level. Which is a b*itch to delete! You basically have to remember every single folder you may have browsed your way into, and delete the .ds_store file there.

The power of Unix. (This will give an error for any dir you do not write perms to. In that case there wouldn't be an .DS_Store files anyway.)

Code:
find <SMB_SHARE> -name "\.DS_Store" -exec rm {} \;

From what I understand, the .ds_store file helps the Mac Finder keep it's view settings for that folder, e.g. viewing as a list, or as icons, etc...Why can't that be stored in a central location on the Mac system itself?

This would be MUCH harder to maintain on a mutli-user system. Plus, it would destroy the concept of your home directory as the place that stores EVERYTHING you need. People are always told: "Backup your home folder. You don't need to worry (much) about anything else.". In your scenerio, the user would also need to remember to backup some hidden system dir or loose all of their Finder/View settings if they moved to another machine or had to restore from backup.

And before we take the Windows bashing any further, remember that SMB shared folders are not Windows specific, Linux and other OSes (including OS X!) can share stuff using the SMB protocol too! I'm sure that if you were connected to a Linux shared folder via SMB from OS X, you would leave all those crumbs (.ds_store, ._filename) around too!

-Ching-Wei

Yes those files would still be there, but like OSX you would never see them (unless you wanted to). Like all Unices, Linux, Solaris, FreeBSD, etc all follow the convention that any file beginning with a "." is considered hidden. (Actually, this is a function of the shell and not the actual system.)

[karbon]

Originally posted by someone_else:

This would be MUCH harder to maintain on a mutli-user system. Plus, it would destroy the concept of your home directory as the place that stores EVERYTHING you need. People are always told: "Backup your home folder. You don't need to worry (much) about anything else.". In your scenerio, the user would also need to remember to backup some hidden system dir or loose all of their Finder/View settings if they moved to another machine or had to restore from backup.

I don't get your logic... It would in fact be a lot easier to maintain, since you had only one file which contained all folder-settings, as one file instead of all .DS_Store files which are littered everywhere! Just make a file in ~/Library/Preferences called com.apple.folderview.plist or something. It would make perfect sense, and you would avoid the problem with a file within every folder. Why is that needed anyway? Only me, as a user on my system, would like to see the folders/files like I see it anyway? A user on another machine with another username has no need for that .DS_Store file being in there!

Yes those files would still be there, but like OSX you would never see them (unless you wanted to). Like all Unices, Linux, Solaris, FreeBSD, etc all follow the convention that any file beginning with a "." is considered hidden. (Actually, this is a function of the shell and not the actual system.)

Well, .files are nice to some extent, but not for the purpose of saving window views/placement/icon arrangement etc. It would be easier to maintain and less stressfull (at least to Windows users) to have it in a single file!

[The DJ]

Originally posted by karbon:


I don't get your logic... It would in fact be a lot easier to maintain, since you had only one file which contained all folder-settings, as one file instead of all .DS_Store files which are littered everywhere! Just make a file in ~/Library/Preferences called com.apple.folderview.plist or something. It would make perfect sense, and you would avoid the problem with a file within every folder. Why is that needed anyway? Only me, as a user on my system, would like to see the folders/files like I see it anyway? A user on another machine with another username has no need for that .DS_Store file being in there!

Well, .files are nice to some extent, but not for the purpose of saving window views/placement/icon arrangement etc. It would be easier to maintain and less stressfull (at least to Windows users) to have it in a single file!

Well, the thing is, apple tried that in OS9. That is why you had to rebuild your Desktop, because the file would get corrupt after a while.
So apple thought, lets's do it in a file inside the folder this time.

The problem is that even this way it is still very prone on getting corupt. The result is that now we have many, many files that need to rebuild and no way to do it. And a very annoying problem when using non mac systems.

DJ

[CharlesS]

Originally posted by ZnU:
What's the benefit in organizing something the user almost never sees?

1. The user can Get Info on their /System directory and see how much space their operating system really takes up.

2. Only a few KB's worth of symlinks hidden at the root of the drive instead of 100's of MB's of hidden files.

3. It would be relatively easy to add a feature to move a system to another drive without a utility like Carbon Copy Cloner, if they just gave the Finder the ability to use sudo to move files as root.

4. It makes life easier for power users who want to read and/or modify config files in /etc.

5. Good organization is something to be desired in itself.

That creates just as much of a mess as having the real files there, of course.

No it doesn't. A few symlinks taking up a few KB's is better than folders containing almost a GB, without question. If there were just a few symlinks there (and a hard link for mach_kernel), it wouldn't be much worse than OS 9 was.

The previous poster seemed to think that this was somehow making the Mac look difficult to use. It's not going to make the Mac look difficult to Windows users, because they're used to worse.

Who cares?

[phrenzy]

So, Is OS X going to leave these little droppings of 5hit when using the new FTP Through finder service?

If so, that is a joke.

If not, why not make the SMB service work the same damn way?

I Understand that Apple wants to accomodate people that may be using SMB Volumes as if they are HFS+ - BUT, come on- SOOOO many people DO NOT use it that way. In fact, I'd say MOST people only use SMB volumes to transfer things like documents, mp3s, avis, html files etc. That have NO NEED for resource forks.

[The DJ]

Originally posted by phrenzy:
So, Is OS X going to leave these little droppings of 5hit when using the new FTP Through finder service?

If so, that is a joke.

If not, why not make the SMB service work the same damn way?

I Understand that Apple wants to accomodate people that may be using SMB Volumes as if they are HFS+ - BUT, come on- SOOOO many people DO NOT use it that way. In fact, I'd say MOST people only use SMB volumes to transfer things like documents, mp3s, avis, html files etc. That have NO NEED for resource forks.

There should be a way to turn this off. Even if it was only somewhere in a plist

DJ

[karbon]

Originally posted by The DJ:


Well, the thing is, apple tried that in OS9. That is why you had to rebuild your Desktop, because the file would get corrupt after a while.
So apple thought, lets's do it in a file inside the folder this time.

If you ask me, that was a very stupid decision... With a multi-user system a seperate plist within the local users preferences folder would make a lot more sense.

The reason for a .DS_Store file within every folder is beyond me, and I am sure Apple is working on a new filesystem, now that they have the new beos guy aboard. We need a database in bottom, keeping every file organized, with types, name and content. It would be nice to also, in addition to just a filename, put a project name on the file, label it etc. It would open endless possibilities for searching, filtering and finding information, and stop the madness we have today...

Just imagine to have something like a "Smart playlist" in the finder, with the possiblity to view files of type "JPEG" and with the project name "Ph.D. paper" which was automatically updated, just like in iTunes3. It would rock the world! People often work on project basis today, and they often want to just see and have access to all files and stuff that goes to a certain project. You could also link iTunes, iPhoto, iCal and Mail together to provide one interface for finding and organizing information.. Man, the possibilities are endless

[The DJ]

Originally posted by karbon:

Just imagine to have something like a "Smart playlist" in the finder, with the possiblity to view files of type "JPEG" and with the project name "Ph.D. paper" which was automatically updated, just like in iTunes3. It would rock the world! People often work on project basis today, and they often want to just see and have access to all files and stuff that goes to a certain project. You could also link iTunes, iPhoto, iCal and Mail together to provide one interface for finding and organizing information.. Man, the possibilities are endless

If you are that disorgenized in your work that you need something like that, then i feel pitty for those persons.
I never understood why ppl have to just dump everything in one folder or even on there desktop. My HD is severely orginized and everything is done with folders. Never ever had one single problem. I don't need such a function at all. Though the develpment op a database FS (journaling i hope) is a good development.

DJ

[karbon]

Originally posted by The DJ:


If you are that disorgenized in your work that you need something like that, then i feel pitty for those persons.
I never understood why ppl have to just dump everything in one folder or even on there desktop. My HD is severely orginized and everything is done with folders. Never ever had one single problem. I don't need such a function at all. Though the develpment op a database FS (journaling i hope) is a good development.

DJ

Well, what you might not need or not is not my problem. As a matter of fact, I didn't need Smart Playlists in iTunes before either, but now that I've gotten used to them it's must. Sometimes you just need to try things to open your eyes. The things we do today often will often look very stupid in 10 years. I think this also can be applied to the filesystem, and the way we organize and use our computers. It's just not very efficient as it is right now, and I am sure it can be done a lot better...

[The DJ]

Originally posted by karbon:


Well, what you might not need or not is not my problem. As a matter of fact, I didn't need Smart Playlists in iTunes before either, but now that I've gotten used to them it's must. Sometimes you just need to try things to open your eyes. The things we do today often will often look very stupid in 10 years. I think this also can be applied to the filesystem, and the way we organize and use our computers. It's just not very efficient as it is right now, and I am sure it can be done a lot better...

i don't use iTunes smart playlists either, believe me, i'm very orginized.
I never suggested that it shouldn't be implemented. Actually i encourage it, as long as it does not get in my way and clutters my OS. (of which i'm sure apple will never let that happen).

But i also think that even the database method is not going to get you what you want. We are still a long way from that. the problem is that even with a database filesystem you still need to designate certain values to a file.
I just want my computer to index my computer at night and assign every file relevent keywords. then such a system will really work. But the required level of AI ( and image recognition for movies for instance) is really high.

DJ

[pat++]

Originally posted by chingwei:
pat++ and karbon: you have opposing views on 10.2 and this hidden file business. Can you tell us which builds each of you are using?

Thanks!

-Ching-Wei

6C115. The server is running win98.

Pat++

[Mediaman_12]

No matter how useful these files may (or may not) be it's another reason M$ windows sys admin. and network tec's will have to keep Mac's off there network. before it was because Mac's where 'chatty' and got blamed for bogging the entire network down. Now even though they can use Windows networking protocols they leave 100's of (unknown to the M$ trained tec's) invisible files everywhere. It will be just another for them to say no to Mac's on there network any time anyone suggests it.

[johann]

well i admin servers that win and mac share files on.. i don't mind these dot files as having it built in to the OS instead of me making users use FTP, or webDAV (IE extra time for me to setup something) is a boon. i just have a simple shell/batch script scrub these directories once an hour for these bad dot files. real admins aren't here to be pains.. we're here to make work easy and smooth for our users. we SUPPORT the work u do. that is our job. any admin that does otherwise should go stick his/her head in a toilet.

[soellman]

those friggin ._files and .ds_store files are the bane of anyone trying to argue that macosx is an "upstanding network citizen."

I understand how the ._ business allows for the macos to retain the dual-forkedness of its funky files on non-native filesystems, although I wish that the network layer of osx (mount_nfs, mount_smb, etc) could just turn off this behavior. This solution is better than the desktopDB EXCEPT for the network repercussions we're talking about. Maybe they should just encode files in macbinary if they're destined for a share. that would be solve one problem and create more.. hmm.

But the .ds_store files I think are unexcusable. So what happens when you have two mac users accessing the same folder? whose .ds_store wins? and how would you feel if you had a group writable directory and all of a sudden you found someone else's .ds_store in there? Apple has gotta fix this somehow. Writing files to network shares in such a willy-nilly fashion has got to stop.

If the behavior in 10.2 is just to make the files hidden, then apple, you're making progress, but you still are a litterbug. find a better way.

But at the same time, I very much empathize with Apple. The reason they get in pickles like this is because they are trying to move computer usability forward, except in this world of interoperability, we find ourselves stuck at the lowest common denominator. File types vs. extensions vs. mime-types? same deal. Yes, I hope the Be FS engineer can rock the boat down there in cupertino.

anyway, back to your regularly scheduled reading..

[chingwei]

Originally posted by soellman:
If the behavior in 10.2 is just to make the files hidden, then apple, you're making progress, but you still are a litterbug. find a better way.

I agree, I don't think making them hidden in Windows is a real solution.

[pat++]

Originally posted by chingwei:


I agree, I don't think making them hidden in Windows is a real solution.

I just verified on my harddisk if files are hidden. YES they are still there but hidden. This is really disappointing....
Apple really think Mac users are not smart enough to see this or what ?

[nickm]

But the .ds_store files I think are unexcusable. So what happens when you have two mac users accessing the same folder? whose .ds_store wins?

The owner of the file/folder trumps everyone. But there is no reason that the system shouldn't store the icon placements and what not in the same file for all users. Practically speaking, though, each user needs his own desktop database that stores this stuff. This shouldn't be a problem on HFS volumes.

[soellman]

Originally posted by nickm:


The owner of the file/folder trumps everyone. But there is no reason that the system shouldn't store the icon placements and what not in the same file for all users. Practically speaking, though, each user needs his own desktop database that stores this stuff. This shouldn't be a problem on HFS volumes.

It's a tough problem, granted. Storing all that in the same file in each directory has its own issues, since a network share may not be in only one security context, and may not share UIDs or unique identifiers between those contexts, so you'd have clashes. This sort of stuff belongs in the filesystem, but again, this is the problem with hetergenerous network environments.

[CharlesS]

Originally posted by nickm:


The owner of the file/folder trumps everyone. But there is no reason that the system shouldn't store the icon placements and what not in the same file for all users. Practically speaking, though, each user needs his own desktop database that stores this stuff. This shouldn't be a problem on HFS volumes.

I thought that was how it worked - the .DS_Store file is world-writable, and contains every user's settings.

[barbarian]

In an era of 200meg HDs who cares about a hidden file that is a few kbytes in size. You'll never see it, and nobody else will either unless they actively go hunting for it. You people sound like those fellows who bitch about microwaves and emissions from overhead electrical lines. The world is full of harmless invisible stuff that makes our lives more convenient. In this case ignorance is bliss.

[soellman]

Originally posted by CharlesS:

I thought that was how it worked - the .DS_Store file is world-writable, and contains every user's settings.

heh.. I didn't realize this, and if this is the case then problem solved (well, the problem of conflicting .ds_stores). But world writable? talk about security problems. more proof that only apple is all talk (in this case) in its idea of being a good network citizen.

[soellman]

Originally posted by barbarian:
In an era of 200meg HDs who cares about a hidden file that is a few kbytes in size. You'll never see it, and nobody else will either unless they actively go hunting for it. You people sound like those fellows who bitch about microwaves and emissions from overhead electrical lines. The world is full of harmless invisible stuff that makes our lives more convenient. In this case ignorance is bliss.

heh.. you don't work for a VC down there in Palo Alto, do you? that's why they all lost their money. the engineers have to pay attention to the details and know their ramifications, otherwise bad things can happen. you don't care what they are though.

btw, I hear if you rip that chickenwire **** out from the inside of the front door of your microwave, it works faster and you can watch your leftovers better.

[CharlesS]

Originally posted by soellman:


heh.. I didn't realize this, and if this is the case then problem solved (well, the problem of conflicting .ds_stores). But world writable? talk about security problems. more proof that only apple is all talk (in this case) in its idea of being a good network citizen.

I don't see it as *that* much of a security problem, given the extremely non-essential nature of these files. I guess if we are both on the same machine and I'm an underprivileged user, and I feel like being a total dumbass, I can delete a bunch of .DS_Stores and make you lose your icon positions. It wouldn't be the end of the world, though, just annoying (maybe enough to get me kicked off the machine if I kept doing it ).

[mitchell_pgh]

How funny would it be to hack into a persons computer and arrange the icons to spell out Y O U S U C K

I don't think those files are writable by world... Isn't it just by users or something...

[CharlesS]

Originally posted by mitchell_pgh:
How funny would it be to hack into a persons computer and arrange the icons to spell out Y O U S U C K

I don't think those files are writable by world... Isn't it just by users or something...

Try it yourself:

find / -name .DS_Store -exec ls -l {} \;

Not all of them are world-writable, but a whole lot of them are...

[chingwei]

Originally posted by barbarian:
In an era of 200meg HDs who cares about a hidden file that is a few
kbytes in size. You'll never see it, and nobody else will either unless they
actively go hunting for it. You people sound like those fellows who bitch
about microwaves and emissions from overhead electrical lines. The world is
full of harmless invisible stuff that makes our lives more convenient. In
this case ignorance is bliss.

(I assume you mean 200gig HDs...)

It's not about the file sizes, and I'm not just bitching for no reason. At
work, we have certain shared folders on the Windows network that contain the
contents of CD-ROMs that we burn and send to our customers. I don't want my
customers to see all these .ds_store files and ask me "what are these for?",
and I'd have to explain "Oh, these files tell my particular Macintosh
computer that I use at work where to put the icons and how to display the
folder contents when I view it on the network....

the .ds_store files are completely meaningless to them, and they just
should not be there.

I'm thinking of an analogy: Consider an art museum. Art is a subjective
thing, and every person will see the same piece of art differently, have a
different interpretation of it, have a different emotion evoked by the
piece.

Now, we like to remember our interpretations of this art, so that the next
time we view it, we might have a better understanding of it. And we tend to
try and remember these things anyway.

Now, if I was a decent "citizen" of this gallery, what would I do: Would I
try and committ the piece to memory, try and remember how I interpreted the
piece in my own head, OR, should I write down my feelings and
interpretations of the piece on the wall next to the piece, or on the piece
itself?

Let's say we do the latter.

Of course, 100's of other people have visited the art gallery. So the walls
are actually cluttered with these little notes and interpretations.

I think you all know what I'm getting at here. First of all, who gave you
permission to write on the walls?

Secondly, doesn't it seem completely inefficient to put your personal
views on a wall that everyone has to wade through to find their own
notes? You are the only one who wants to view the piece in your way, so why
wouldn't you keep the note with you, in your pocket, or in your own brain?

Since the view of an object is a function of the viewer, it should be stored
with the viewing entity, and not with the object.

Whatever, this doesn't solve my problem, anyways...that sucks...

-Ching-Wei