MacOS files -> windows

[Dr_Charles_Forbin]

Hi - hoping someone out there has run into this before and has a solution... after a lot of explaining to AppleCare they basically said "not our problem". MacOS stores certain files as "forked" - they separate the metadata from the actual file content. When you copy the file to an external device like a USB stick, it creates shadow copies of the file that are (at least I think, not a lot of doc on MacOS file structure, especially AFPS) which contain the metadata for the file. When you pull this over to windows, even in a exFAT formatted file systems - the metadata isn't reconstituted to the file content as appears with a ._ prepend, and also has the DS_store folders. How do we reconstitute/convert these files so they're readable by a windows file system? I'd appreciate any help, and TIA.
[doublepost=1541649764][/doublepost]Just updating - found an inelegant but workable solution. Spawn a windows vm on the Mac and drag the files to windows, then copy them to the USB stick. PITA but it works. Any other solutions out there?

 

[Ritsuka]

99.9999% of your files does not have a resource fork. You can just discard the ._ file. You have to worry about resource forks only if you are using apps on the classic Mac OS, so it would mean a 20 years old app and system.

 

[Dr_Charles_Forbin]

Well then perhaps I don’t have a fork but I do have shadow files that certainly resemble the appearance of a forked file being created. Even the directory names are shadowed. I checked and it’s clearly from the copy to the USB stick on the Mac... invisible to finder but clearly present in terminal.\

By the way - for anyone looking - there's an undocumented (seemingly) utility called dot_clean on the mac that gets rid of this problem. It has to run through terminal as dot_clean /Volumes/... (whatever the path name is). Wish Apple would have mentioned that to me on the call or/chat thread.

 

[dwig]

99.9999% of your files does not have a resource fork. You can just discard the ._ file. You have to worry about resource forks only if you are using apps on the classic Mac OS, so it would mean a 20 years old app and system.

Actually, the extra resource files that the modern macOSs create at still used, but now only contain stuff-and-nonsense that the OS uses, primarily Finder. I've yet to find any files that are missing useable metadata when moved to a Windows machine.

I do find the dot files annoying. The macOS is configured to hide them from view, but Windows will reveal them. For some of my copying to drives used for cross-platform access I use FreeFileSync to do the copying. I have a filter set to ignore a range of file names, both the macOS dot files and the Windows "desktop.ini" files.

 

[Dr_Charles_Forbin]

Actually, the extra resource files that the modern macOSs create at still used, but now only contain stuff-and-nonsense that the OS uses, primarily Finder. I've yet to find any files that are missing useable metadata when moved to a Windows machine.

I do find the dot files annoying. The macOS is configured to hide them from view, but Windows will reveal them. For some of my copying to drives used for cross-platform access I use FreeFileSync to do the copying. I have a filter set to ignore a range of file names, both the macOS dot files and the Windows "desktop.ini" files.

[doublepost=1541698489][/doublepost]It was strange - people say the files are unused but when I deleted the shadow file for a .class file - it came up completely unformatted. Before that it came up with the original text spacing in the class file. Unfortunately there aren’t any really good sources on Mac administration any more - latest ones I saw are circa 2005/2006. I’m tempted to buy the support guide for the support class but I’m waiting to hear back from them on whether developer registration entitles me to this doc.. I assume theirs is more current than whatever is published.

 

[chown33]

There's more than just resource forks that ends up in the ._ "shadow" files. Every extended attribute also gets written there.

You can use the 'ls' command in Terminal.app to show what extended attributes are attached to a file:

ls -leO@ FILE_NAME_GOES_HERE

Obviously, put the actual filename where FILE_NAME_GOES_HERE is.

For further info, see the man pages for the 'ls' command, and also see the 'xattr' command.


Text editors might use xattrs or the resource fork to store some formatting info. You'd have to tell us which editor you used, and what language the .class file is for.

The only .class files I'm familiar with are Java class files, but they're the compiled byte-code classes, not the source you'd edit. Java source files are .java suffixed.

 

[Dr_Charles_Forbin]

There's more than just resource forks that ends up in the ._ "shadow" files. Every extended attribute also gets written there.

You can use the 'ls' command in Terminal.app to show what extended attributes are attached to a file:

ls -leO@ FILE_NAME_GOES_HERE

Obviously, put the actual filename where FILE_NAME_GOES_HERE is.

For further info, see the man pages for the 'ls' command, and also see the 'xattr' command.


Text editors might use xattrs or the resource fork to store some formatting info. You'd have to tell us which editor you used, and what language the .class file is for.

The only .class files I'm familiar with are Java class files, but they're the compiled byte-code classes, not the source you'd edit. Java source files are .java suffixed.

I find it hilarious that the Apple support techs were taking to me like I had 3 heads when I was trying to explain this to them. These are supposed to be the experts. Yes, they are .java files.. my bad. I sent them screenshots though.. showing the problem on the Mac only with the files in terminal and finder .. and they told me “not their problem” after explaining the whole thing to the tech. Talk to MS or Oracle-not our problem. I got so pissed off this morning - I shot an email to Tim Cook. I don’t expect it to go anywhere but I told him if I wanted that kind of an answer - I’d talk to paid MS support.

 

[chown33]

... How do we reconstitute/convert these files so they're readable by a windows file system? I'd appreciate any help, and TIA.

I think one way is to use a disk format that can write extended attributes. NTFS is such a format, but Mac OS can't write it by default. You have to add an extension to Mac OS that allows writing NTFS. Paragon and Tuxera are two examples. You can find more by googling keywords such as: macos write ntfs

Another possibility (not tested by me) is to use a file-server that supports extended attributes. I don't recall what's supported by which file servers, so you'd have to look it up.

Depending on the Windows VM, I think that drag-and-drop uses a "file server" (or file service) when copying files to and from a Windows VM. I don't recall where I read that, but it was certainly at least a few years ago.

Even if extended attributes are supported by the target file-system, I'm not sure that whatever editor you're using on Windows will read the formatting info from the Mac-specific xattr. Storing some metadata will be platform-specific, so there might be zero compatibility of the metadata between platforms. Since I don't think you've told us which editor you're seeing the problem in, I can't be more specific.

If you post your Terminal screenshots here, maybe someone can explain them.

Imagine that you're trying to provide enough detail for someone to replicate the problem on their own Mac. Write your descriptions and post screenshots with that in mind, and it will at least be something to go on. Right now, you haven't given anywhere near enough detail to replicate anything.

In my experience, Apple support people don't know much about Terminal, so asking them questions that involves Terminal or "programmer-type things" can be unfruitful. I once did get an escalation to someone with more Terminal skills, but that was years ago, and I had a carefully framed question that I took the time to write out in full.

 

[Dr_Charles_Forbin]

I think one way is to use a disk format that can write extended attributes. NTFS is such a format, but Mac OS can't write it by default. You have to add an extension to Mac OS that allows writing NTFS. Paragon and Tuxera are two examples. You can find more by googling keywords such as: macos write ntfs

Another possibility (not tested by me) is to use a file-server that supports extended attributes. I don't recall what's supported by which file servers, so you'd have to look it up.

Depending on the Windows VM, I think that drag-and-drop uses a "file server" (or file service) when copying files to and from a Windows VM. I don't recall where I read that, but it was certainly at least a few years ago.

Even if extended attributes are supported by the target file-system, I'm not sure that whatever editor you're using on Windows will read the formatting info from the Mac-specific xattr. Storing some metadata will be platform-specific, so there might be zero compatibility of the metadata between platforms. Since I don't think you've told us which editor you're seeing the problem in, I can't be more specific.

If you post your Terminal screenshots here, maybe someone can explain them.

Imagine that you're trying to provide enough detail for someone to replicate the problem on their own Mac. Write your descriptions and post screenshots with that in mind, and it will at least be something to go on. Right now, you haven't given anywhere near enough detail to replicate anything.

In my experience, Apple support people don't know much about Terminal, so asking them questions that involves Terminal or "programmer-type things" can be unfruitful. I once did get an escalation to someone with more Terminal skills, but that was years ago, and I had a carefully framed question that I took the time to write out in full.

Thanks - I have it. I didn’t really get it until yesterday when I stumbled on an old post where they talked about forking a metadata file from content and then I saw it immediately. I used to be a document management SA so I’m pretty familiar with the separation of metadata from content and it makes sense if you don’t have a registry (thank God). There’s a utility NATIVE to Mac that gets rid of these files and reconstitutes the metadata and content together..it’s really pretty brainless... it just needs to be run from terminal. I think what pissed me was the “it’s not our problem” attitude. Its an old, known issue. I don’t mind someone not knowing something - yes it should be in their KB, but not everyone has as much OS experience or intuitive understanding as we do.. damn, I’ve been through 6 OS (MVS, DOS, Windows and all its flavors, HP-UX, Solaris, AIX and now Linux and Mac OS) - not as an SA but as a DBA which you need to know a decent amount of internals for. I didn’t expect L1 to know the answer - I figured L2 would at least say - ok, let’s look into it and not brush me off. I gave kudo’s to a L1 support that really took the time to try and understand the issue and took good notes. Also, admittedely, I have a bug up my ass about paying for crappy support. But, in all seriousness, thanks for taking the time to answer me.

 

[chown33]

FWIW, you can run 'dot_clean' from an Automator action, saved as an application that accepts folders, and invoke it much more simply in the future. This assumes that its use from Terminal is a hindrance to you. If you're fine with occasional Terminal use, ignore this post.

 

[Dr_Charles_Forbin]

FWIW, you can run 'dot_clean' from an Automator action, saved as an application that accepts folders, and invoke it much more simply in the future. This assumes that its use from Terminal is a hindrance to you. If you're fine with occasional Terminal use, ignore this post.

Thanks for the heads up .. great idea. It’s not that it’s me - I’m fine in terminal - it’s my daughter doing it. She developing in Java using NetBeans on the Mac but her school computers are Windows and they need to use a USB stick to transfer the project files. She didn’t want to use the Windows VM this semester and shes not a CS major so no biggie. She’s been telling me since the beginning of the semester that the files aren’t going over right and until a couple of days ago when she sent me a snapshot of the directory on windows did I see the “shadow” files being created. At first we thought the project was corrupt, then I’m thinking that their inbound virus scan is making a shadow copy because the files would be corrupted.. NetBeans couldnt open them and if you delete the ._ files the text loses its formatting and looks like a string (probably because of the 0a0d translation getting screwed up). So it’s a banging a head against the wall kind of thing until I just lucked out on a google keyword search and hit that post and then the light bulb came on.