Windows CF file transfer preserving executable flag & ToolTypes?

[Photon]

Problem: These are lost on my FAT32 swap card for transferring files.

Alternatively, does one of the Commander programs support PFS or FFS on CF?

Solution wanted for unarchiving multiple lha/zip files directly to the CF card. Visually and with as few clicks as possible. (Ideally, select a few with the mouse and right-click or press a keyboard shortcut and pop them over.)

Cheers for answers.

[StevenJGore]

Use WinUAE (in administrator mode) and unzip in AmigaOS onto an Amiga-formatted card to preserve everything.

I have a WinUAE config just for this purpose, it's a basic AmigaOS 3.2.2 installation with DOpus4 and the card mounted as a drive. Then I just put it back in my A1200.

[Cylon]

WinUAE puts a file with the extra flags in a single file in the touched directory.
Tooltypes are stored in the .info file; if you keep that they are preserved.

only file attributes are not part of the file itself but only of the filesystem and need to be preserved.

[Photon]

Originally Posted by StevenJGore

Use WinUAE (in administrator mode) and unzip in AmigaOS onto an Amiga-formatted card to preserve everything.

I have a WinUAE config just for this purpose, it's a basic AmigaOS 3.2.2 installation with DOpus4 and the card mounted as a drive. Then I just put it back in my A1200.

Yes, this is always available. Direct however means to save seconds or minutes. Optimizing.

Originally Posted by Cylon

WinUAE puts a file with the extra flags in a single file in the touched directory.
Tooltypes are stored in the .info file; if you keep that they are preserved.

only file attributes are not part of the file itself but only of the filesystem and need to be preserved.

The .info file was copied for the slave, so the options must be stored in the .info file for the folder containing the slave then. OK, I didn't know that. I guess I'm allergic to extra files holding info for other files!

Edit: It's not really logical to assume that a file outside a folder holds information vital to the survival of the rebellion, I mean vital for label display names of a .slave file inside a folder.

OK so maybe my question is reduced to: FAT32 can cope with the executable flag and the problem is only with a non-Amiga old zip version that didn't support it (when zipping)?

Still would be nice with a thing like that. Some program that saves src and dst folder and select a few files -> copy or unarchive to dst, no worrying about messing up folder structure like with e.g. WinRAR (which I don't use).

[wiser3]

AmigaDOS allows longer path names and some special characters that FAT32 does not. A common problem with unzipping to FAT32 is missing files because path name was too long and file names changed because the special characters get dropped. You may not have had this problem but it's nice to keep in mind for the future.

[Photon]

Originally Posted by wiser3

AmigaDOS allows longer path names and some special characters that FAT32 does not. A common problem with unzipping to FAT32 is missing files because path name was too long and file names changed because the special characters get dropped. You may not have had this problem but it's nice to keep in mind for the future.

Do you mean file/folder names? Cos extraction path is different, it can be quite long depending on archive folder depth.

File/folder name length is known and hasn't been a problem so far (decades of extracting).

The external folder .info containing ToolTypes for files inside the folder is now known, I had no idea it was this bad. I guess you need a compiler to 'compile' the icon for the folder. That's ... terrible. :O

The only mysterious thing left is why the occasional executable flag is missing. Could be the uploader just using a crappy or old archiver. Which can only be fixed with protect #? rweds - unless a special 'Commander fixes it on the fly, I guess.