Aqua Taskforce

jasper wrote on October 1, 2008, 6:52am

I don't see the problem. The folder has been modified, and having a ds_store in every folder makes sure that an entire database (like in 0S9) can't be corrupted at once, and if it is corrupted, it should only restore one folder. I also don't see what the problem is with creation dates and everything... But for that, I won't demote you. But still, I just wanted to say that the central file tree would be more malicious than you think.

MicrowaveDave wrote on October 1, 2008, 7:33am

But Jasper, the folder has NOT been modified by ME. Why should the act of opening and viewing folder contents count as a modification? If I can't trust a folder's modification date to reflect the time I actually modified it, then it becomes useless and dangerous. You mention creation dates but the problem I'm talking about is MODIFICATION dates. The folder contents were not modified, but an invisible system file was added without my permission. It would be easy to add the .ds_store file silently and keep the folder's original date, similar to how photo editing applications can be set to rotate a photo without changing the modification date.

If I only want to copy recently modified folders to a backup drive, it becomes impossible to distinguish new folders from old ones when *ALL* the folders I opened have been modified simply by looking at them. Sometimes only a small folder with 1MB of files has been changed on a hard drive. Next time you use a backup utility, instead of just backing up that one file, it could back up hundreds of megabytes or gigabytes, thinking that the folders have been modified, even though they were simply viewed. This is ridiculous. I do work for publishing houses who have huge archives, which were all sorted by folder modification date. With the advent of OS X, they had to come up with complex and expensive indexing methods which simply weren't needed in OS 9.

If you think a central file tree is malicious, you must hate the Spotlight index, which just happens to be a central file indexing tree, and becomes corrupted very easily, uses up memory, slows down the computer and causes other problems etc etc etc. I personally don't see the difference between the OS 9 Desktop DB and the Spotlight index. Both contain metadata, and can contain information about each and every file and folder on the hard drive. The main difference is that OS 9 had a Rebuild Desktop utility, which Spotlight does NOT have.

abitgone wrote on October 1, 2008, 7:52am

Regardless of who modified the file system, it has been modified, and OS X's filesystem is simply reporting the correct information.

jasper wrote on October 1, 2008, 9:12am

First of all, Spotlight uses a seperate tree that uses DS_STORE files to find it's information. Having one huge tree means that if corruption comes up, you can't save anything up in the tree, it'll be lost or hard to retrieve. Why doesn't spotlight have a rebuild desktop? Because spotlight indexes your system seperatly. Spotlight is an applications that reads through these trees and has nothing to do with your file system per sé, it just uses it's own way to quickly find files.

Also a central tree containing all files and indexing all the time slows down your system and it just isn't that versatile. And spotlight is not an OS, or file system - it's just an index that maks it easier to find files - like a table of contents. Finder is used to allocate, store and use files.

Also, MacOS X makes DS_STORE files in a folder by standard, so only if it's the first time you open a folder that it makes this file and edits the modification date. Why is this good for your backup utility? Not all files get backed up again if you have a good utility - the utility should notice that the folder was modifed, but not any files. A decent backup application should then just backup the DS_STORE file and leave the rest where's it at. Since decent backup utilities back up files, not 'folder's, that's not all bad and it only happens once.

Sorry, this is nonsens and just and example of how you seem to be unable to adapt to a new system used on Mac. (No I'm not saying that you have no ground to stand on, but the needs of many are more important than the needs of one). DS_STORE files make it easier to safely have all your files in a system, without a full tree that could be corrupted. Demote.

MicrowaveDave wrote on October 1, 2008, 9:26am

Spotlight does not store any information in .ds_store files.

Please do your homework before posting.

jasper wrote on October 1, 2008, 9:54am

I never said that. Spotlight uses the DS_STORE files to read the data and then enters that in it's own tree. Do your extended homework and you would have understood. Spotlight doesn't index just the files, it uses DS_STORE to peep.

If that's your only reply, though, there is no need for this thread.

ebaur wrote on October 1, 2008, 8:12pm

If you are backing up entire folders based on the modification date of the folder itself, you might want to look at the way you are backing things up. You should be inspecting the files themselves for modification dates.

For example, in my testing right now (from the command line, Finder results may vary), modifying a file does *not* change the modification date of the folder. This makes some sense, because the directory itself has not changed. The "contents" of a directory is the list of inodes/files that it contains, nothing more. Only addition or deletion of things in the directory listing modify a directory, not changing the contents of those files.

MicrowaveDave wrote on October 1, 2008, 10:55pm

Of course Finder behaviour is different. It's the only application that writes .ds_store files. The command line, and every other piece of software in existence, ignores them. I still don't think it's acceptable for the OS to randomly modify dates on folders, because the user has not modified the folder. I say randomly because it only creates the .ds_store file sometimes, not always. Windows does not change the modification date when it adds thumbs.db files into a folder, and nobody complains because it's done silently in the background.

Forget backup utilites. I am not talking here just about network admins who know all about network utilities and the command line. The Mac is supposed to be user-friendly. Most home users do not use backup utilities, they just copy important stuff to CDs regularly. For many years users have sorted projects by Date Modified, so they know what the most current folders are. This also works VERY well in a group environment because everybody can see current files when they list them by Date Modified. When the OS randomly goes and changes dates, the entire list is sorted completely randomly. This would be like my secretary randomly placing 8 year old files in my In box. It makes for confusion and annoyance. Publishing companies who put files on CD to deliver to printing bureaus often just want to copy the most recently worked on folders onto a CD. When the two most recently modified folders aren't actually the ones that they worked on, they have to go searching through the list for things. It's confusing, inconsistent and doesn't make sense. Yes I know that technically the OS has added a file, therefore the folder has been modified. But terminal junkies are the only people who think like this. Normal users just scratch their head and wonder why their computer keeps changing things without their knowledge.

The entire point of this website is to point out an annoyance with OS X. If it doesn't annoy you, shut up and just demote it already. Don't tell try and tell me it's not a bug, it's a feature.

ebaur wrote on October 1, 2008, 11:20pm

Yes, you're right, Mac OS is supposed to be user friendly. I actually do understand why you're annoyed at this, and that's fine. My point is that if the behavior was changed it would only succeed in annoying other people who are expecting the current behavior.

Your example of the Windows thumbs.db file is apropos - but you're wrong that no one complains. When I'm working in Windows, I frequently get annoyed that there are folders that *have* had updates to them that have *not* have the modified date updated. I know I'm not the only one, at least where I work. You may think that makes sense, but it's the wrong solution.

I agree more with your other idea... I think the .DS_Store files are, largely, a disaster. However, for the time being, I'm not sure I see a better way for Apple to accomplish what they wanted to do with those. Still, changing it so those didn't get created unless the file itself is modified would go a long way in mitigating what you're talking about. (Having a large central database won't work, BTW, since the data wouldn't be portable between machines... portability was a large reason for introducing them in the first place.)

Remember, they want it to be user-friendly, but they can't break compatibility with other systems / standards just so your favorite workflow habits stay intact. Feel free to complain, but some of us are trying to point out why you shouldn't get your hopes up, or why we'd be just as annoyed as you are if the behavior changed. Take that for what it's worth and don't read too much into it.

polycat33 wrote on October 2, 2008, 4:27am

It seems like this issue would be fixed simply by making it so that hidden system files cannot affect the overall folder modification date information. That seems reasonable to me, they're hidden for a reason, and their effects should be hidden too. In normal use, a person or company would only be sorting folders and looking for files based on items they put there, and not these system files that are meant to hide in the background. Regardless of whether or not everyone thinks this is a big problem, it seems like there's a pretty easy solution that wouldn't affect the way other people who don't think this is a problem use the finder.

jasper wrote on October 2, 2008, 2:47pm

Good Old OS9, Dave. Good Old OS9. Do you even get internet on that thing anymore?

I admit this might be a quirk, but I don't see exactly where the problem lies. What is the problem here? That your backup utility is set up to check folders instead of altered files? That Windows adds thumbs.db and MacOS X interprets that as a new file, so it's edits the folder? That every folder you make using OSX automaticly has a DS_STORE file and therefore doesn't need to create a new one, and therefore the modifcation date of that folder is the day you created it, and the days you edited it yourself? FInder makes these files - and it's doesn't remake those files anymore unless they're deleted..

ebaur wrote on October 2, 2008, 3:11pm

Not to belabor the point, but I just did some more testing... and, as I suspect, you can't rely on folder modification dates at all (which has actually been my opinion for quite awhile on all OSes, including classic Mac OS). Let me enumerate for you:

1) Editing a file does *not* update the modification date of the folder it's in.
- Editing with Text Edit does, mysteriously... that's because Text Edit doesn't edit, it actually creates a new file. The folder mod date changed simply because the folder *was* modified, an entry was deleted and a new one created.
- I was able to use Text Wrangler to modify a file w/out the mod date on the folder changing.

2) We keep talking about the Finder... but it's just a small application that lives on top of the filesystem. These changes would have to FS changes, and OS X supports a number of them (HFS+, UFS, ZFS). The Finder might be able to affect behavior with the .ds_store files, but I'm not sure that the filesystems allow for other apps to change a modification date arbitrarily. (???)

3) Even if the filesystem attempted to update the mod date of the folder when a file was edited, I realized that this would be an intractable problem. The issue is that a file doesn't actually know what directory it is in.
- I realized that, with hard linked files, the filesystem doesn't actually know all the folders that the hard linked file lives in. It would only be able to modify the folder that was used to open that copy (maybe), and that would lead to very inconsistent behavior.
- Interesting, this means using Text Edit to edit hard linked files is "dangerous" as it will break the linkage. (Which is kind of scary if you edit system files with Text Edit, although hard links are rare, I don't want to take a chance.)

4) Changing the way the Finder, or the filesystem, deals with hidden files is not a good solution, either. There are other files that are hidden that contain data that needs to be tracked. The .ssh folder, the .bashrc and .bash_profile, to name a few.

5) The behavior we have now is very consistent, both within OS X and across other Unixes... I don't think that should be broken just to fix a minor annoyance. This is especially true when it opens a huge can of worms of other problems to solve.

By the way, if you have a backup utility or some other program that needs to know quickly where file system updates have occurred, you can inspect the FSEVENTS database (it's actually a series of files in /.fseventsd/). Those contain a list of all directories that have had any sort of file system event in. This is used by Time Machine, among other things, to track changes more quickly than by scanning the entire filesystem when it runs.