strange behavior when trying to modify or delete pre-existing files/folders

I came across a very odd problem the other week when troubleshooting a failed migration on a Mac going from Entourage 2004 to Outlook 2011: it seemed that any file or folder created prior to the upgrade attempt became “locked” by the OS (OS X 10.6.8 in this case) and any attempt to edit or delete it required administrator access. Mind you these files were in the user space and a permissions check on both the command line and the GUI proved that this user had full read/write access to their own files. Any new file or folder created could be modified or deleted as normal. Other symptoms include: copying files from a network drive to the desktop do not inherit read/write permissions of the owner of the desktop (and require administrator access to modify/delete), and sometimes copying files from other places (sharepoint drive, network folders, internet downloads, etc) results in an error message that the filename exceeds 255 characters and cannot be copied. Sometimes you’ll receive a numeric code in an error message if you fail to authenticate as an administrator when trying to delete these files.

Reimaging the Mac doesn’t help, neither does moving the user files to another partition, then recreating the user and moving the files back over and giving them full r/w permissions.

The message about exceeding 255 characters got me thinking along the lines of Windows filename length restrictions. Checking the formatting of the hard drive revealed that it was definitely partitioned as GUID, and was using Journaled HFS+, so that wasn’t it. I decided to experiment with copying a few of the suspect files off to an old FAT32 formatted thumb drive, then copying them back to the Mac. Sure enough I was able to modify and delete them as expected without admin authentication. I’m thinking that this is a result of FAT32 ignoring the Mac file attributes it does not understand and basically “removing” them. As a consequence of copying the files to a FAT filesystem, the attribute that was requiring admin authentication to edit the file was removed, allowing me full access again.

The same principle applies when storing Mac files on non-HFS filesystems, so the rule of thumb here is to always compress the Mac file(s) by zipping them or storing them in a dmg (the two most common methods) since you never know where the file will end up. In this case i wanted Mac attributes removed, but usually I do not want that.

It’s also worth noting that I don’t think the upgrade attempt caused this problem, but brought out this underlying problem with this particular Mac.

About this entry