txt file originally created from within XP does create one. _ files.Oddly, renaming a Safari-saved file as foo.txt and opening it in TextEdit and saving does _not_ create a. Drag and drop of these files also does not generate. _ files.Files saved from OmniGraffle and Safari _do_not_ generate. Drag and drop from Finder of these files to a Windows share creates. txt doc on a Windows share, then open it from TextEdit and save changes, I get an AppleDouble resource fork file.Ditto for saves from Excel, Word, and PowerPoint. Up to this point I'd assumed that OS X was doing this.If I create a. Originally posted by AMSR:What app are you using that creates resource forks? _ critters would be so easy to wipe out in *seconds* with a periodic shell script: find -x /folder/path -name '._*' -delete with all the bloat in windows you'd think these tiny. View image here: - Bugs are usually something that cause actual problems. Now, if you want to request a feature be added to OSX to appease other operating systems. "definitely in Apple's court to fix" - View image here: -"report this as a bug to Apple" - View image here: - Sorry Charlie (will be their reply): it "works as expected". Originally posted by Sanook:This is definitely in Apple's court to fix, at least a finder option to include or exclude the data on network shares. except -EMake a custom rsync script to do file transfers (and even add an "-exclude-from=" list, to skip over. Rsync -acPvx /path/to/source /path/to/target So - instead of using Finder (or cp) to copy from Mac to Windows - use something which allows us to turn off xattrs.One way i know of is to use rsync: I'm not interested in hiding them on the Windows side (since they vastly outnumber me) I want to suppress their creation altogether, and metadata be damned! AFAIK, "dot underscore" (._*) files are only created when an item is copied by some program that supports extended attributes. I'm the only Mac in a Windows office, and my Mac is littering all the shares with. (3) CREATE a server-based tool that will automatically clean up these extraneous files on the server, which should then percolate down to the clients.Quote:Originally posted by stevenkan:Title pretty much says it. (2) SUPPRESS the recursion of these attribute files on the Dropbox server (and thus on the unsupported filesystem), and (1) WARN a user who is trying to link to an unsupported filesystem (an FS other than HFS and NTFS) that it is not advised and the user will experience side effects, such as all these extra tag/attribute files, (SHAME on Dropbox for not already having this simple mechanism in place!) So, Dropbox, there are FEW things you need to do: file that appears on a filesystem (like FAT or ExFAT) that does not natively support tags and extended attributes, but they sure as heck are responsible for all the recursion! Dropbox may not be liable for the very first. But is Dropbox completely to blame? Not 100%, I would say. Now I've got numerous recursive files overrunning my file system and clogging my resources. I encountered this recently on my MacBook Pro, when I decided to create an exFAT partition for common files between OSX and Windows, such as the Dropbox folder.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |