OS4Depot and FTP uploads

I have now added experimental FTP uploads to OS4Depot as a result from the previous thread .

Please test it if you wish.

I wrote up a guide here . Let me know if there's anything missing.

It worked for me (tm) while developing it, but as always there might be some quirks here and there.

Does anyone want to create an aminet<->os4depot readme converter?

It would be a shell application that takes two files as input.

- The aminet readme file and a file with the os4depot specific fields.

or

- The os4depot readme file and a file with the aminet specific fields.

This way the way a developer would only have to maintain one of the files and then run the converter when it's time to upload the files.

There's no way of a comment to the moderators accidentally being missed and ending up in the .readme on the site is there? If I'm reading the instructions right, I could just type a message on the first line, and have the name: field be the 2nd line?

And out of curiosity, does the order of the headers matter?

By the way, when you upload to the site, or replace a file, the site always adds a linefeed to the end of the readme. If you continually upload new versions without changing the readme, you'll end up with many blank lines at the end. Hadn't bothered to mention that before because it's just a minor thing.

@MickJT

Quote:

No not as long as it's before the "hend:" tag. The parser extracts everything it doesn't recognise in the header and puts it in a separate comment file. The comment file is then discarded once the file is approved. The readme that actually ends up in the approval queue is a separate file from the one you upload. It's basically the parsed/interpreted result of your uploaded readme. For example, the passphrase does not end up in the final readme since the readme can be read by anyone on the site. Any sensitive information is stored separately.

I don't expect many FTP-uploaders to add comments though but rather use FTP upload as an automated way to upload, in which case you don't want to mess up your local readme file with temporary comments. But the feature is there nevertheless.

Quote:

Nope. Only that some fields are required and that they have the correct length and/or contents. The order that they appear in the header does not matter.

Quote:

Okey I'll look into it.

@orgin Quote:
This is less easy than it sounds, because Aminet readmes must be word-wrapped, while OS4Depot readmes should not be word-wrapped (although people often do).

For best results I would recommend only converting from OS4Depot readmes to Aminet readmes. That way the program can automatically insert line breaks as required. Going in the other direction would require it to guess when to join lines together (which will be very error prone).

That also means the program will need to be told maximum line lengths (before it adds line breaks). "0" could be used to tell it to not word-wrap, for the cases where the OS4Depot readme is already word-wrapped.

@ChrisH

You just need to set the word wrap limit slightly less than the auto wordwrap limit of os4depot.

@broadblues Quote:
OS4Depot has automatic fixed-length word-wrap?!? From my experience it just let the web browser auto word-wrap to the window (as normal HTML files do).

Is this a recent change? (That would be a step backwards IMHO.)

@ChrisH

It hasn't changed since 2004.

The raw readme isn't word wrapped. The formatting is kept as it's submitted. Only the presentation on the web site is automatically word wrapped (Or rather, row wrapped at 80 characters) but this does not alter the raw readme text.

OS4Depot accepts both wrapped or non wrapped text.

It would be nice if the requirement for the "ftp" username was dropped, or alternatively if the password was not empty.

Why? Because when a username is required, FTP Mount assumes that a password is also required, and since the provided password is empty, FTP Mount thinks I haven't provided a password, and so asks me for one. The GUI itself does accept an empty password, so one click lets me log in.

Not a major problem, more just a minor annoyance. Of course it would be better if FTP Mount were fixed, but that seems quite unlikely

@ChrisH

"ftp" is the standard anonymous FTP username. Just leave username and password empty and FTPMount will connect anonymously.

IIRC password should be your email address, rather than blank, for anonymous FTP.

@orgin
Thanks for the FTP support. It already made uploading a new version of PortablE much more straight forward.

@orgin

I tested the FTP upload. I had "hideemail: yes" in the header but the email is visible. Could you hide it ?

@orgin
My email address seems to be visible too, even though I had specified for it to be hidden. Please hide it!

Emails removed. Let me know if I missed a file.

I'll look into why it doesn't become hidden.

The hide email flag should now work as intended.

@orgin
I have a SUSPICION that the "replaces:" field isn't working as intended. At least, the first time I uploaded a REPLACEMENT archive, it seemed to be accepted, but then I realised it was missing the "replaces:" field, so I added it & re-uploaded it, and then the Uploads page reported "Invalid or missing replaces field."

This is what I used, which I think is correct:
Quote:

edit: Looks like it's case-sensitive (error message not very helpful!)... but that still doesn't explain how I was seemingly able to upload without the "replaces:" field at all!

P.S. Personally I think the "replaces:" field should be allowed in the very FIRST upload, because otherwise it's easy to forget to add this field in a subsequent update. OR ELSE it should be possible to comment-out fields, so they can at least act as a reminder they need uncommenting for a future update.

@ChrisH

I've made the field case insensitive now.

I checked the code and you can leave "replaces:" empty provided that there is no previous file with the same category and filename.

Beyond that it's not possible to detect if a file is the first upload since that would be the same as stating the wrong filename.

Edit: I suspect that you were able to upload with no replaces field before because it didn't think that OdysseyLauncher2.lha was the same file as odysseylauncher2.lha (linux file system magic) and thus treated it as a new file.