Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Another solution?' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Another solution?
Authored by: Phoenix1701 on Mar 09, '03 09:33:27AM

It seems to me the most logical (and simplest to implement) solution for this mess would be as follows:

If the filesystem is UFS, all bets are off. Do whatever you can with the little you have to work with, or just stop supporting UFS at all (why is it supported anyway?)

Otherwise, create a .DS_Store file in each user's home directory, containing custom view information for each folder the user has seen. Be sensible and use filesystem reference IDs rather than absolute paths, so the whole thing doesn't break when the user renames or moves a folder. If a .DS_Store file is present on a read-only volume, use it instead unless the main .DS_Store file already contains an explicit entry for that volume (to allow for spiffy disk images with custom backgrounds and positioning, etc). In all other cases, write data out to the (singular) .DS_Store as it changes rather than waiting for logout.

Can anyone find problems with that...? It works for multiple users, doesn't break read-only volumes, gets rid of the problem of Macs littering remote servers with rogue .DS_Store files, and doesn't depend on filesystem-specific metadata except reference IDs (which are such a good idea they really should always be there, UFS be damned). If you see a hole, perhaps we can fix it... otherwise, <a href="http://www.apple.com/macosx/feedback/">tell Apple!</a>



[ Reply to This | # ]
Couldn't understand your scheme
Authored by: noworryz on Mar 09, '03 01:46:00PM

I'm afraid I couldn't understand your scheme. If the .DS_Store files (actually new database files as was suggested in an earlier comment) are only written in the user's home directory, how would they get on read-only volumes? How do you set up a CD so it looks good?

I also don't understand your distinction between HFS+ and UFS, since they both use the same .DS_Store file, at present. Basically both file systems are treated the same, as far as the Finder is concerned, except when the .DS_Store files are missing.

-- Glenn

[ Reply to This | # ]

Couldn't understand your scheme
Authored by: Phoenix1701 on Mar 10, '03 05:41:45AM

Well, as for the question about CDs, the idea was that if the current folder is on a read-only volume, the Finder will look for a .DS_Store file in that directory first before referring to the global one in your home directory. Therefore, to make a CD look the same on all machines, just include a .DS_Store file on it. (Of course, you'd have to do this with some program other than the Finder... Disk Copy perhaps?)

In regards to the UFS/HFS+ issue, the reason I draw a distinction is because -- to my knowledge -- UFS does not support filesystem IDs for files. (If that's wrong, and Apple has just been using hard-coded paths for things for no reason whatsoever, someone on the Finder team needs to be throttled.) Therefore, the entire scheme I suggested would break on a UFS volume. :(



[ Reply to This | # ]
DS_Store files do have file names
Authored by: noworryz on Mar 10, '03 10:25:01AM

The .DS_Store files do have file names in them -- that's so they can work on UFS volumes. Furthermore, the characteristics of folders move with their names. You can prove this by renaming a folder in the terminal, creating a new one with the old name, and relaunching the terminal. The new folder you created will have the old folder's characteristics (background, etc.). The .DS_Store mechanism apparently does not use HFS+ file IDs at all.

The .DS_Store files do not have full paths names in them. There is no need, for the file names always refer to the files and folders in the same directory.

All this is easily verified using HexEdit and some simple experiments.

[ Reply to This | # ]