Hacking Question On Mac, is it specifically Finder that messes up the archive flag?

[hippy dave]

Does copying to SD from the command line avoid the problem?

If so, that sounds like a fine solution for me and a lot of people, but it might leave an opening for a nice Switch File Manager app (for Mac, not Switch) for people who like to keep things GUI. Guess it could also deal with the dot files before ejecting.

 

[sirAnger]

Does copying to SD from the command line avoid the problem?

If so, that sounds like a fine solution for me and a lot of people, but it might leave an opening for a nice Switch File Manager app (for Mac, not Switch) for people who like to keep things GUI. Guess it could also deal with the dot files before ejecting.

The next version of Hekate payload (3.1) will have an option to clean the archive bit from the /switch folder. I've compiled it and it seems to work. That said, I can test to see if copying via terminal works better. By my guess, the problem is the source files have the archive bit, so the destination files will have it too. Doesn't matter how you copy.

 

[hippy dave]

The next version of Hekate payload (3.1) will have an option to clean the archive bit from the /switch folder. I've compiled it and it seems to work. That said, I can test to see if copying via terminal works better. By my guess, the problem is the source files have the archive bit, so the destination files will have it too. Doesn't matter how you copy.

Thanks, let me know how your testing turns out.

 

[sirAnger]

Thanks, let me know how your testing turns out.

Doesn't appear to fix the issue. I'd say wait for Hekate 3.1 on this. CTCaer says the testers are making sure everything is good. Anticipates a release some time today.

 

[hippy dave]

Doesn't appear to fix the issue. I'd say wait for Hekate 3.1 on this. CTCaer says the testers are making sure everything is good. Anticipates a release some time today.

Alright, thanks. I thought I saw someone say it was Finder doing it, maybe I misinterpreted. Yeah I'm waiting for 3.1 anyway to make sure I have a guaranteed backup.

 

[noX1609]

Sounds interresting.
Where/How can i change the archive bit and what have to be changed?
Would like to test it out if thats the reason hbmenu don‘t see homebrews on a exFAT SD.

 

[mav2010]

Sounds interresting.
Where/How can i change the archive bit and what have to be changed?
Would like to test it out if thats the reason hbmenu don‘t see homebrews on a exFAT SD.

On the terminal, you can use this command:

sudo chflags -R arch /Volumes/<name of SD card>

Ideally followed by

sudo dot_clean /Volumes/<name of SD card>

to remove the hidden Mac specific files.

 

[hippy dave]

On the terminal, you can use this command:

sudo chflags -R arch /Volumes/<name of SD card>

Ideally followed by

sudo dot_clean /Volumes/<name of SD card>

to remove the hidden Mac specific files.

But it's since been figured out that you shouldn't change the flag on the Nintendo folder or its contents.

 

[noX1609]

But it's since been figured out that you shouldn't change the flag on the Nintendo folder or its contents.

Why? Does it corrupt the files?
The only thing i want to achieve is that the homebrews are detected so i try first to just remove the bit from the /switch/ folder and files in it, hopefully that will do the trick

 

[hippy dave]

Why? Does it corrupt the files?
The only thing i want to achieve is that the homebrews are detected so i try first to just remove the bit from the /switch/ folder and files in it, hopefully that will do the trick

Yeah people have had their legit games stop working and have to be reinstalled.
Yeah doing the switch folder should be safe and achieve what you want, that's the solution ctcaer has settled on for the fix option in his latest ipl build.

 

[sirAnger]

Why? Does it corrupt the files?

Yea. It seems to be hit-and-miss, and it might be a firmware specific thing. I've found when messing with the archive bit on the official Nintendo folder, it makes it so my switch can't see anything inside it, whether they are all on or all off. Some files are required to be on and some off. So it's best not to mess with it.

The only thing i want to achieve is that the homebrews are detected so i try first to just remove the bit from the /switch/ folder and files in it, hopefully that will do the trick

That worked for me, for the most part. If you use homebrew apps that deal with the file system (like FTPd or NX-Shell) the directories with the archive bit set will show as 0-byte files instead, and will not allow you to view their contents. If you don't use these apps you should be fine. If you do use these apps, or you use other apps that give weird errors, then maybe try to set the archive bit on everything manually avoiding the Nintendo directory.

On a separate note, the 3.1 version of Hekate is out that allows you to unset the archive bit on all files in the /switch directory. Unfortunately this doesn't set it on any other files in the SD. I made a request to @CTCaer with some updated code, hopefully he can get something into the next version. If that might take a while (I know he has other things on his plate) I can distribute my version on request (if he is OK with it).

 

[noX1609]

Thanks for the information about the new version of hekate.
Will try if that works because if it does then i only have to do it once and after that i can switch back to SX OS.
When i inject the payload for hekate where is the option to change the bit located?

 

[hippy dave]

Somewhere in the Tools menu.

I noticed last night that the command-line copy command, "cp", has a -X flag that looks useful for this:

-X Do not copy Extended Attributes (EAs) or resource forks.

 

[sirAnger]

Somewhere in the Tools menu.

I noticed last night that the command-line copy command, "cp", has a -X flag that looks useful for this:

Interesting. I'll see if that works when I get a minute.

 

[DocKlokMan]

Does copying to SD from the command line avoid the problem?

If so, that sounds like a fine solution for me and a lot of people, but it might leave an opening for a nice Switch File Manager app (for Mac, not Switch) for people who like to keep things GUI. Guess it could also deal with the dot files before ejecting.

Microsoft are the ones that made the exFAT filling system. Microsoft are also the ones that made the Archive file attribute. Windows automatically sets the archive bit for any new files copied to external devices in order to mark them as needing to be backed up when using backup software. This is a very old feature that's been carried along into modern version of Windows and most backup software doesn't rely on the archive attribute any longer but Windows will still set it when copying files.

On macOS their backup software has never used the archive attribute (called a flag on macOS) and so macOS doesn't set the archive flag when copying new files to exFAT as it's never had to.

Normally this presents no problems but with the Switch, however Nintendo decided to implement Microsoft's version of exFAT, they set it up so that the archive attribute needs to be set or else the Switch can't enumerate the files in the directory. If a file is directly called by its path (such as hbmenu.nro on the root of the card) that's fine, but if it needs to list the contents of a folder, the files are practically invisible if the archive attribute isn't set. It's general consensus that this is just an oversight by Nintendo.

TL;DR: Nintendo implemented exFAT oddly on the Switch and no, Terminal won't help, though other 3rd party file copiers may.

 

[GerbilSoft]

Normally this presents no problems but with the Switch, however Nintendo decided to implement Microsoft's version of exFAT, they set it up so that the archive attribute needs to be set or else the Switch can't enumerate the files in the directory. If a file is directly called by its path (such as hbmenu.nro on the root of the card) that's fine, but if it needs to list the contents of a folder, the files are practically invisible if the archive attribute isn't set. It's general consensus that this is just an oversight by Nintendo.

That's not just an oversight; that's fundamentally broken. I don't think any backup software even uses that bit anymore, since it's usually better to check timestamps and file sizes as a "quick check" instead of the archive bit.

For what it's worth, this is the first time I've heard of Switch ignoring files without the archive flag set.

 

[sirAnger]

Somewhere in the Tools menu.

I noticed last night that the command-line copy command, "cp", has a -X flag that looks useful for this:

cp -X didn't work.

@AnalogMan that's some good insight. Thanks!

 

[CTCaer]

That's not just an oversight; that's fundamentally broken. I don't think any backup software even uses that bit anymore, since it's usually better to check timestamps and file sizes as a "quick check" instead of the archive bit.

For what it's worth, this is the first time I've heard of Switch ignoring files without the archive flag set.

Mine's the opposite. Every game breaks if I have the archive bit in Nintendo folder's contents.
^^

EDIT:
I think we can all agree that's fundamentally broken.
This should only happen with hidden attribute (and ofc course how a software reacts on it).

 

[noX1609]

@AnalogMan: Thanks for the detailed explanation.
Will try that later but before changing i will look at what flags are set atm so i know if i have to remove or set the archive bit.

 

[hippy dave]

Well this just gets less and less clear cut.

Leaving the files that the Switch puts in the Nintendo directory the hell alone is a safe bet, or if backing up/transferring them, being sure to use a method that leaves everything the same.

But for other files on the card... Homebrew launcher definitely needs the archive bit unset? The ftp server struggles with it? Does the driver used for ipl care at all, or SX OS's bootloader?