The workaround is simply to LHA the disk images before transferring them to the OS4 machine. When I un-LHA them at the other end the file comments are intact. It's an extra step but it's not the end of the world.
Also, I'm being lazy - I have pen and paper, I could just write down "Disk1.adf = Samples, Disk2.adf = Med Songs" and so on. I just thought I'd store the info in file comments instead and save the paper and ink.
(I'm dumping about 200 old disks for a friend to preserve the contents before he sells the kit)
It could be that server gives the outer IP address instead of local IP address to establish a passive data connection and that might mess things up if you don't have port forwardings properly set for outside connections. So it could very well be the issue still. Passive is better for outside connecitons, but active may work better on LAN.
I haven't known about that catch in a LAN. I didn't expect it to pass out outer IP addresses.
I have been caught with active and passive before when remotely connecting to a server with MS FTP command. I needed to change this script to use passive. Maybe it has an esoteric use but for the most used OS in the world I was surprised to find it wouldn't work easily. But later found out it can be forced to work after editing a hex key (as I call it). In the end I just gave up and downloaded another ftp program to use. Perhaps it's common to outsource. I mean, if you can download Python now, would anyone bother sticking with 80's MSDOS batch scripting? Even AmigaDOS scripts look superior in use and handling
Quote:
As told, comments aren't stored in actual files or their headers. Files just aren't touched in any way and their size doesn't change when you modify comments. It's a filesystem specific feature and filesystem stores it somewhere where it stores other metadata about files. It would end up with horrible mess if comments would be stored in the actual files.
Well, I would call it a file header, where name size and other attributes are stored. So apparently it's called a FileListEntry where the comment is called. In a file list of a directory.
Quote:
FTP only sends binary data of the file, no dates or any other info, and client asks for a file by its filename. The FTP protocol really isn't designed to be used with automated (graphical) clients. It's up to client to parse a human readable text based directory listing to get whatever info is provided in that. Practically all FTP servers (including Amiga servers) send the directory listing in UNIX standard listing format nowadays, which is the same as you get with the "ls -l" command in *nix systems. So, what clients are able to parse about the list is *nix protection bits (not Amiga), user and group (not much use in Amiga), file size, date, and filename. It's up to client what information of these it uses, filename is the only one really needed to retrieve files.
I mostly use FTP with a GUI client. Usually FileZilla which has "Opus" file listers. But I do find it lacks obvious features like changing dir on both local and remote when there is a matching folder name. I found out about the Unix underpinnings of FTP when setting up RC-FTPd on my A1200. I don't recall what happened with Amiga protection bits. I used to transmit files over FTP to other machines like Mac. And mostly, to decrease transfer size and keep bits intact, would LhA it first.
Quote:
Nothing stops writing an FTP client and server that would support Amiga's file attributes, but they would only work between themselves and no other client or server would understand them. There have been tens of different listing formats in the past and it's been a mess.. luckily there's kind of de-facto standard nowadays.
Most if not all OS or file systems would have attributes and comments. The Amiga has GUI/UID but it's an optional extra. I'd say FTP could be expanded to include bits and comments but if it's not there already too late to append the standard.
The workaround is simply to LHA the disk images before transferring them to the OS4 machine. When I un-LHA them at the other end the file comments are intact. It's an extra step but it's not the end of the world.
That's also what I do as well. Since years. Takes time and RAM or HDD space but works for me.
Unfortunately, for some reason, not all Amiga users are aware of this. I have no idea why. I've seen Amiga people copy Amiga files to USB stick or even unpack on Windows for some reason then transfer to Amiga using some other generic medium and wonder why they have problems later. I didn't think I was too smart for my own good, but I don't know why they do this. I mean, does anyone unpack Windows or Linux files on their Amiga, copy from an Amiga file system to Windows or Linux, the complain the executables are faulty? If not, why do the opposite?! Lol.
Where I have seen problems is where a basic CDFS turns all files into upper case and strips bits. I've seen this happen a lot when transferring or installing OS3.9 in UAE. For some reason all my UAE Workbenches suffer from this glitch.
i like ZitaSync very much and you have a quick solution to transfer photos under AmigaOs4.1 directly from your cell phone. I also watched your video - it's great I would be interested in such a solution!
I didn't understand exactly how it works, does the client that receives the data/photos run under AmigaOs4.1 ? How is a connection established?
ZitaSync monitors filesystem changes on your phone, and uploads anything new to your computer via FTP. ZitaFTP Server is the other half of the system. It'll have an easy way to set up the connection between computer and mobile device.
Right now I have a very rough proof of concept that I paid someone to create. It works, but needs major rework to be reliable.
Quote:
I also like ZitaFS and I will soon be faced with the problem of having to transfer data from my A1222plus to MacStudio and vice versa. I already have ZitaFTP, but it is too complicated for me to make FTP connections available on both sides, it should run automatically and be available when I need it quickly as I can currently do with SMB2Fs.
ZitaFS works similar to SMB2Fs?
Maybe you can write a little more about how it works and how it is set up and what requirements need to be met. In the end I always opt for the simplest variant that is available under AmigaOs4.1.
ZitaFS is at the idea stage.
ZitaFS will be a filesystem that scans the network for FTP servers, and then allows you to access them as if they were a local drive. You'll also be able to add other FTP servers to the list.
I'd say it's more like FTPMount than SMB2FS. ZitaFTP Server will also be the other half of the system, providing network shares. I may also support some other protocols & cloud services like Amazon S3.
For AmigaOS,** the goal is to finally fill the hole that was left when Envoy stopped being developed. We don't have a good system for sharing files between machines. Samba is a pain in the butt to set up. I've never had a copy of Envoy, and it's showing its age, anyway. I want something that works as seamlessly as file sharing on other systems.
The workaround is simply to LHA the disk images before transferring them to the OS4 machine. When I un-LHA them at the other end the file comments are intact. It's an extra step but it's not the end of the world.
Yes, that works.
It is possible to preserve things such as file creation & modification dates, and unix permissions. However, there's no uniform standard. Actually, for reading all file meta-data is theoretically posisble via the MLSD command from RFC 3659. Alas, it doesn't have a way to upload the file meta-data.
There's an expired draft extension with MFMT, MFCT, and MFF commands (link) which some servers implement. Others go *NIX and have SITE UTIME & SITE CHMOD.
Support for these commands varies from client to client, and server to server, so the whole thing is a big mess. This is why Filezilla can preserve file timestamps, but you have to enable it manually, from the transfer menu.
Adding those commands to ZitaFTP Server is on the to-do list. This is how ZitaFTP and ZitaFS will be able to support AmigaOS filesystem meta-data. Well, for AmigaOS-to-AmigaOS transfers at least, I don't know if it's possible to preserve AmigaOS file metadata on other systems like Windows.
I mostly use FTP with a GUI client. Usually FileZilla which has "Opus" file listers. But I do find it lacks obvious features like changing dir on both local and remote when there is a matching folder name. I found out about the Unix underpinnings of FTP when setting up RC-FTPd on my A1200. I don't recall what happened with Amiga protection bits. I used to transmit files over FTP to other machines like Mac. And mostly, to decrease transfer size and keep bits intact, would LhA it first.
Officially, FTP has no UNIX underpinnings. However, the specification's LIST command is very ambiguous, and so UNIX servers used "ls -l" format. Eventually, this got so common that it became the de-facto standard.
The MLSD command in the RFC 3659 extension does it properly, and supposed to replace LIST. However, being an extension, not all clients or servers support it. It's on the ZitaFTP Server to-do list...
Officially, FTP has no UNIX underpinnings. However, the specification's LIST command is very ambiguous, and so UNIX servers used "ls -l" format. Eventually, this got so common that it became the de-facto standard.
Yeah, FTP listing isn't really designed to be machine-readable. At the time the protocol was developed, it was assumed that a human user reads what's printed on a text based console screen, and do his own interpretations. Nobody thought that some day there would be GUI clients that need to interpret listings programmably.
Even nowadays "ls -l" isn't always enough. I had to add custom parsing for MT32-Pi in RNOXfer, for example.
In 90s/00s I ran an FTP server on Amiga (patched/recompiled wu-ftpd), and many Windows clients (like CuteFTP and WS-ftp) were expecting something else than UNIX standard, so the host type setting had to be changed manually on them to get it work properly.
Exactly. Likewise, ZitaFTP Server identifies itself as "UNIX Type: L8" instead of giving the actual SYSTem type because some FTP clients won't work with anything else. The SYST command is effectively useless.
One advantage of me writing both the FTP server and client, is that I can make sure they work together properly.
Thanks for the brief explanation of ZitaSync and ZitaFS, I have registered as an interested party and hope that something really useful for us will come out of this project, with which we can quickly and easily transfer data from different systems under AmigaOs4.1 in the future.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
I'd be interested in the commercial Envoy replacement, especially if it can share and connect to any USB device on another computer (USB over IP). A screen sharing feature would be handy, too :)
Officially, FTP has no UNIX underpinnings. However, the specification's LIST command is very ambiguous, and so UNIX servers used "ls -l" format. Eventually, this got so common that it became the de-facto standard.
That would explain it then. It is hidden well within a GUI. And not noticeable using a HTTP FTP server.
Quote:
The MLSD command in the RFC 3659 extension does it properly, and supposed to replace LIST. However, being an extension, not all clients or servers support it. It's on the ZitaFTP Server to-do list...
After looking it up much of the info about MLSD is about server time outs. Surprisingly a lot of shared info about FTP commands doesn't give any details on how to use it. Is this such accumulated knowledge that every IT person is expected to know the format of every FTP command off by heart? Well, description part of a file looks closest to a comment. I thought comment was a common way of describing a comment, rather like dialog has become a common word, but it seems comments are still hard to find. Though having said that the Linux desktop gives no options for setting file comments. Surprised it's that basic.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
