tired of this CRAP
- Thread starter solrac
- Start date
solrac
Mac Ninja
The refresh button gives the user power. But I agree, it is not classic Apple.. so why not just hide it in the customize tool bar window? If you want to add it, just customize your toolbar but would be hidden by default. And, to add to the refresh button, bring back Apple's polite automatic refresh. Users should have both. The more choices, the better.
And DS_Store is not the only invisible file!!
If you access a windows drive (at least when doing this), and you copy files over this is what happens:
Mac Folder contains:
hello.txt
music.sit
you copy to windows drive (or zip disk? Or CD?)
Copied folder contains: (UGHH)
.DS_Store
.trashes
._hello.txt (tiny, useless file)
._music.sit (tiny, useless file)
hello.txt
music.sit
Very bad, very sloppy, very un-polite... very un-mac-like. Apple needs to fix this. Where is the feedback section of Apple's web site? It should be on the home page!!!
Thanks,
-solrac-
vanguard
Registered
A process executes in it's own memory space. Forking is when a process starts a new process (or is it thread?). It takes a lot of work for the machine to open a new process, use it once, then close it. My solution would have done that for every file.
The advantage of my solution was that it would work for an unlimited amount files. The disadvantage is that the computer would have to work harder for every file found.
His solution is faster but it can't handle a very large amount of files.
This is the Mac OS X feedback page:
http://www.apple.com/macosx/feedback/
Although, now that solrac has pointed out that a similar situation exists in the opposite direction, it behooves Apple to figure out some fix for hidding files in both directions in order to always stay one step ahead in ease of use.
http://www.apple.com/macosx/feedback/
Although, now that solrac has pointed out that a similar situation exists in the opposite direction, it behooves Apple to figure out some fix for hidding files in both directions in order to always stay one step ahead in ease of use.
I agree, the .DS_store sucks and the solution to keeping stuff from transferring is to intentionally put it in the resource fork of HFS+. I think folders can and should have a cache file like thingy, but why not have it be the resource fork of the folder instead of a file?
I'm sure Apple is aware that this sucks and they wouldn't have done it if they didn't have to, but I agree, it bears repeating to Apple that it should go away.
Refresh should be handled by the application, sending an AppleEvent to the finder afet medifying an icon so the finder knows to update its view. If your app isn't doing this, yell to the app maker, the responsibility lies there.
I also agree that a refresh buuton could be allowed to force a refresh but shouldn't show up by default because it isn't needed by default and just confuses most users and unnecesarily clutters most desktops.
I'm sure Apple is aware that this sucks and they wouldn't have done it if they didn't have to, but I agree, it bears repeating to Apple that it should go away.
Refresh should be handled by the application, sending an AppleEvent to the finder afet medifying an icon so the finder knows to update its view. If your app isn't doing this, yell to the app maker, the responsibility lies there.
I also agree that a refresh buuton could be allowed to force a refresh but shouldn't show up by default because it isn't needed by default and just confuses most users and unnecesarily clutters most desktops.
GadgetLover
Senior Member & Tech Guru
Once upon a time there lived a little girl named dottie-dee-ess (her friends called her .DS). Dottie had a little black thread running through her neck. HEr parents told her never to touch the thread (so she didn't). The kids at school used to tease her and say, "There goes Dottie-Black-Thread." The thread never bothered Dottie herself and never got in her way. She could shower with it and play sports and climb trees. Everything a little kid likes to do (she coould even use her folks new flat-panel iMac with her threaded neck!). One day her best friend Upto Nogood said, "Dottie, why don't you pull that damn thead out of your neck; it's annoying!" Dottie said, "Oh, I don't know, my parents told me not to." "F@#k your parents," exclaimed Upto. "Just Do It!" So Dottie, ever so slightly, pulled that little black thread from her neck until it was completely out. Then her head fell clean off! -Thud!- (oops!) 
The moral of the story is: if it ain't broke, why fix it!?
The moral of the story is: if it ain't broke, why fix it!?
GadgetLover
Senior Member & Tech Guru
Originally posted by theed
but if my head were held on by a thread, I wouldn't have lived past 3. I want that bastard file gone.
That's what Dottie thought! -Thud!-
P.S. What the @#*$ is the "SymSecondary Launch" app in the login window for? Is that a Norton (Symantic???) app. Anyone else have this freak of an app listed in their Login window??
francofranchi
Registered
Sorry, guys, but I believe you're addressing the issue bottom to top. The real problem is not having annoying files/folders visible/invisible in your disks. The crucial point is that Apple's filing system went back a decade or two by imposing a different file naming and structure. It's worthless taking care of the symptoms (these kind of files are an example of them) if you don't care the hillness per se. I suggest you subscribe a public petition to Apple posted in the Internet a month ago asking for a re-thinking of the file system, starting from the issue of using a suffix instead of the beloved type/creator fork, to arrive to file unchangeable names, obliged directories, etc. I'm still a defendant of OS X, but the file structure and its rigidity is really what sets me up. For the non english users, like me, for example: what's the purpose of being able to have applications in so many different languages, and not being permitted to localize folders and application names?
Krevinek
Evil PPC Tweaker
Unfortunately, the issue is partially with Apple, partially with others. One strength of *nix is the ability to seperate the actual FS implementation from the kernel. This has the strength of being able to support any FS as long as there is a kext for it. The drawback is the fact that HFS/HFS+ is the only FS designed with multiple file forks of late. Everything else is a single fork system, and the kernel/etc Apple adopted doesn't have complete support for it. The HFS+ support for forks is faked through CarbonLib. I believe Cocoa doesn't even have multi-fork support in the API.
The idea on other OSes is that metadata is the OS' responsibility, not the filesystem itself. Now I would like to see Apple switch to a MIME-based metadata scheme taking advantage of the .DS_Store file Apple already has, maybe by moving the file into a larger DB at the root, although Apple probably split it up like this to prevent large-scale DB corruption (remember those fun things in pre-OS X systems that made you reformat because the Desktop file got corrupted? BTW, that Desktop file was essentially what .DS_Store is now)
Plus, on a *nix system, any .<Blah> file/folder is supposed to be hidden, so having them show up in FTP is the fault of either the FTP client or the FTP server. It could be either. Quite a few FTP clients are set to display hidden files by default for some silly reason.
Yes, it could use improvement, but to be blunt: We are still asking the wrong thing.
The idea on other OSes is that metadata is the OS' responsibility, not the filesystem itself. Now I would like to see Apple switch to a MIME-based metadata scheme taking advantage of the .DS_Store file Apple already has, maybe by moving the file into a larger DB at the root, although Apple probably split it up like this to prevent large-scale DB corruption (remember those fun things in pre-OS X systems that made you reformat because the Desktop file got corrupted? BTW, that Desktop file was essentially what .DS_Store is now)
Plus, on a *nix system, any .<Blah> file/folder is supposed to be hidden, so having them show up in FTP is the fault of either the FTP client or the FTP server. It could be either. Quite a few FTP clients are set to display hidden files by default for some silly reason.
Yes, it could use improvement, but to be blunt: We are still asking the wrong thing.
TheeIronChef
Registered
It's useful to delete them from any websites' folders you might be uploading to a webserver.
Sometimes Fetch complains that it can't delete a folder if the folder isn't empty, and Fetch in OS X can't see the .DS_Store files to delete them.
Sometimes Fetch complains that it can't delete a folder if the folder isn't empty, and Fetch in OS X can't see the .DS_Store files to delete them.
You could just copy only the visible files to the windows computers at your office, and that way they don't get the .ds file.
Use a utility to make the finder show invisible files, I use one called "Tweaker" (which has an awesome icon!), you can find it at www.versiontracker.com.
I've never tried this solution, but it seems that it should work and result in no .ds_Store files on the windows computers.
Another alternative is, next time your Windows-using office compatriots whine about the .ds_store files, just haul off and bitch-slap 'em. Then you don't have to listen to their crap anymore.
Use a utility to make the finder show invisible files, I use one called "Tweaker" (which has an awesome icon!), you can find it at www.versiontracker.com.
I've never tried this solution, but it seems that it should work and result in no .ds_Store files on the windows computers.
Another alternative is, next time your Windows-using office compatriots whine about the .ds_store files, just haul off and bitch-slap 'em. Then you don't have to listen to their crap anymore.
Izzy
luv my lil' malteaser
I too share your apprehension about going into the terminal...it seems like too many customizations and work-arounds require tinkering with things that with one wrong letter or space could really screw up the system...
...although I only have one nutsack to spare...LOL
TommyWillB
Registered
This is not new, nor exclusive to OS X. OS 9 and earlier all do the same thing when writing to Novell file servers... except the files are named something else. (can't remember the filenames???)
TommyWillB
Registered
I'm not conviced you have...Originally posted by theed
but if my head were held on by a thread, I wouldn't have lived past 3. I want that bastard file gone.
Krevinek
Evil PPC Tweaker
Let me put it this way, .DS_Store is just the new form of the Desktop files we are so used to being annoyed with under OS 9, just in a method that *nix GUIs seem to do.
These issues of hidden files popping up is definitely not new, you try sharing your main boot drive using FTP or something and watch all the OS 9 crap show up like 'Desktop DB' and 'Desktop DF'. There was a reason for this switch, but Apple has not taken the time to explain it to the "common user".
One of the reasons is that it is a little easier to work with drives suffering from fragmentation when you don't have your constantly changing database locked down to one file strewn all over your HD's platters.
The other reason is it makes it easier to move the metadata from one machine to another. If I burn a CD or make a stuffit archive of a folder, all the metadata is assured to go with it, including which app to open the files inside with. You don't get this with Stuffit archives all the time, so comments, etc may be lost. If Apple wants to expand the current .DS_Store structure, they can, and still retain the mobility of that extra metadata.
Plus, what if your HD crashes and you need to do a recover, or inodes corrupt and you start losing folders that you can't recover for one reason or another? With a centralized DB, you lose out if it is all attached to a single location and that DB dies. You get extra excess entries that are invalid if you lose inodes (folders).
I personally think .DS_Store is a better mechanism than the older Desktop structure. We still have the issue of FTP servers that show hidden files by default, but that is the FTP server's issue, not the OS'.
These issues of hidden files popping up is definitely not new, you try sharing your main boot drive using FTP or something and watch all the OS 9 crap show up like 'Desktop DB' and 'Desktop DF'. There was a reason for this switch, but Apple has not taken the time to explain it to the "common user".
One of the reasons is that it is a little easier to work with drives suffering from fragmentation when you don't have your constantly changing database locked down to one file strewn all over your HD's platters.
The other reason is it makes it easier to move the metadata from one machine to another. If I burn a CD or make a stuffit archive of a folder, all the metadata is assured to go with it, including which app to open the files inside with. You don't get this with Stuffit archives all the time, so comments, etc may be lost. If Apple wants to expand the current .DS_Store structure, they can, and still retain the mobility of that extra metadata.
Plus, what if your HD crashes and you need to do a recover, or inodes corrupt and you start losing folders that you can't recover for one reason or another? With a centralized DB, you lose out if it is all attached to a single location and that DB dies. You get extra excess entries that are invalid if you lose inodes (folders).
I personally think .DS_Store is a better mechanism than the older Desktop structure. We still have the issue of FTP servers that show hidden files by default, but that is the FTP server's issue, not the OS'.
I understand the old invisible files on MY computer issue, and I avoided this by sharing a folder within the volume rather than the root volume. Now the issue is that even looking at a folder on someone else's machine can create kruft on their system. This contamination is completely new, and irritating.
The desktop file for unwriteable volumes (like CD's) was a RAM only structure in 9. Why can't mounted volumes have a RAM only DB? What's in those files anyway? Why should other people's viewing preferences be affected by what I do with the windows? It'd be one thing if they were only created to hold forked data, but they seem to be created willy nilly, and without my consent.
If they are just cache files, I want the option to make them RAM only on foreign volumes. If they hold resource fork, why do they show up on HFS+? I'm not pretending to have a solution, because I don't know what problem they were solving when they made the .DS_Store, but I don't like it, and there are other valid solutions for every reason I can come up with.
The desktop file for unwriteable volumes (like CD's) was a RAM only structure in 9. Why can't mounted volumes have a RAM only DB? What's in those files anyway? Why should other people's viewing preferences be affected by what I do with the windows? It'd be one thing if they were only created to hold forked data, but they seem to be created willy nilly, and without my consent.
If they are just cache files, I want the option to make them RAM only on foreign volumes. If they hold resource fork, why do they show up on HFS+? I'm not pretending to have a solution, because I don't know what problem they were solving when they made the .DS_Store, but I don't like it, and there are other valid solutions for every reason I can come up with.
Krevinek
Evil PPC Tweaker
Welcome to the wonderful world of *nix. I have had the (un)fortunate experience of dealing with this day in and day out under Linux.
Actually, AFAIK, early MacOS did do this, but later, it moved to a disc structure, defaulting to the RAM structure when using non-HFS discs. You can't actually store and move metadata if it is RAM-only. These files don't contain forked data, but people seem to be complaining about their existance. You try to store metadata inside a file on a UDF partition, it doesn't work since you don't have extra forks. As I said, these files are the new Desktop files. Do you complain about that repository of metadata? I doubt it.
They aren't cache files, they store the metadata required for the folder and every file inside that folder. Exactly what metadata is being stored there I can't figure out quite yet. Nothing I have under 9.2.2 will open them. It is as if they don't exist, even while visible. Plus, if you were designing a system to be filesystem independant, then you would be producing those files on both HFS+ and UDF partitions, since it simplifies development. You just call into a specific API for the FS and handle the metadata yourself. This allows for an easy way to plug new FS kexts into OS X. Heck, I wouldn't mind putting OS X onto an ext2 partition