ioFTPD v6.2.0 Beta Released

[hukker]

Hoy boys.

ioftpd 6.2.1.0 nxtools 1.05a iosfvv2.0beta1.56 win2k3

Ive been getting a few crashes lately and theese are the last entries in the crash.log file.
Anything you recognize?

Unhandled exception 3221225477 at address 0x7c8224b2 (0x00000000)
0x00000000 0x45000000 
Unhandled exception 3221225477 at address 0x7c8224b2 (0x00000000)
0x00000000 0x450124a5 
Unhandled exception 3221225477 at address 0x7c8224b2 (0x00000000)
0x00000000 0x8e391802 
Unhandled exception 3221225477 at address 0x7c8224b2 (0x00000000)
0x00000000 0xda0b4503

[Yil]

Heya hukker. Unfortunately 0x7... addresses are usually stack related and essentially impossible to debug with just an address though it's interesting that they appear to all be the same. TCL essentially runs on the stack so I'm starting to think I should poke around there a little bit...

I strongly suggest grabbing the debug version I posted earlier in this thread and getting a dumpfile of the crash that you can send to me so I can play with it...

I've had a report of the debug version failing with a debug assertion failure under vista in one of the MS library routines. I'll look into this as soon as I get a vista environment to play with

[tuff]

Originally Posted by Zer0Racer

I have 70+ lines of vfs rules, for both dirs and files, and it has been working for years and it still works

how about posting that

[Zer0Racer]

Originally Posted by thunk

ZR have you tried this? Because I CAN'T get it to work.
Maybe it's just overwrite, I will assume it works for upload/mkdir if you say so.

Overwrite = */foo.nfo *
Overwrite = * 1MV

Now place foo.nfo in any subdir on your ftp and try to overwrite the file with another foo.nfo. It will result in the following:

[R] (19:17:29) REST 0
[R] (19:17:29) 350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
[R] (19:17:29) STOR foo.nfo
[R] (19:17:29) 550 foo.nfo: Permission denied.
[R] (19:17:29) Transfer Failed

Works the same way for Overwrite. When I tried Overwrite = * !* I got Permission Denied, but when I added Overwrite = */foo.nfo * above it it worked.

[22:55:30] [L] STOR foo.nfo
[22:55:30] [L] 550 foo.nfo: Permission denied.
[22:55:30] [L] Transfer Failed!
 
[22:55:54] [L] site rehash
[22:55:54] [L] 200 config Command successful.
 
[22:55:59] [L] STOR foo.nfo
[22:56:00] [L] 150 Opening ASCII mode data connection for foo.nfo.
[22:56:00] Transferred: foo.nfo 8 KB in 0,17 seconds (50,7 KB/s)

Maybe you have some other vfs rule that stops the upload?

/ZR

[Zer0Racer]

Originally Posted by tuff

how about posting that

My 70+ lines of vfs rules are highly specific for my own site. Might not be of any use for others, but I'm sure it's possible to create some examples that are. Care to contribute? We can start a new thread with "VFS detailed permissions tips & tricks"

/ZR

EDIT: btw.. I've also created an ioFTPD.ini wordfile for UltraEdit :P

[thunk]

Originally Posted by Zer0Racer

Maybe you have some other vfs rule that stops the upload?
/ZR

None that I know of.
I had no success doing it like this. What IO version are you using?
And Yil, can you confirm that it works already?
I'm still using the old 5.8.5 ... had no time to upgrade and modify all my scripts yet
But I didn't see anything about this in the changelogs so I figured it would still be the same behaviour..

[Zer0Racer]

Originally Posted by thunk

I'm still using the old 5.8.5 ...

Works the same way in 5.8.5. I even went back to my backup setup of that version and tried.

[09:38:01] [L] site version
[09:38:01] [L] 200-Running ioFTPD version 5-8-5r
[09:38:01] [L] 200 Command successful.
 
[09:38:05] [L] STOR foo.nfo
[09:38:05] [L] 150 Opening ASCII mode data connection for foo.nfo.
[09:38:05] Transferred: foo.nfo 8 KB in 0,13 seconds (69,8 KB/s)
 
# Overwrite = * !*
[09:38:26] [L] STOR foo.nfo
[09:38:26] [L] 550 foo.nfo: Permission denied.
[09:38:26] [L] Transfer Failed!
 
# Overwrite = */foo.nfo *
# Overwrite = * !*
[09:38:38] [L] site config rehash
[09:38:38] [L] 200 config Command successful.
 
[09:38:41] [L] STOR foo.nfo
[09:38:41] [L] 150 Opening ASCII mode data connection for foo.nfo.
[09:38:41] Transferred: foo.nfo 8 KB in 0,13 seconds (69,8 KB/s)

So either you doing something wrong or there is another vfs rule somewhere in your ioFTPD.ini because it's there you get the error msg "Permission denied".

/ZR

[tuff]

people just love spending time searching for problems that dont exist

[thunk]

Yeah tuff, I took 4 days off from my well paid job just to be able to spend time searching problems that don't exist ;F.

ZR:

[R] (22:10:27) site version
[R] (22:10:27) 200-Running ioFTPD version 5-8-5r
[R] (22:10:27) 200 Command successful.

[R] (22:11:39) site config show VFS
..
[R] (22:11:39) 200-058: Resume = * *
[R] (22:11:39) 200-059: Rename	 = * 1VM
[R] (22:11:39) 200-060: RenameOwn = * *
[R] (22:11:39) 200-061: Overwrite = */foo.nfo *
[R] (22:11:39) 200-062: Overwrite = * !*
..

ufxp overwrite:
[R] (22:14:04) Opening data connection IP: xxx PORT: xxx
[R] (22:14:03) REST 0
[R] (22:14:03) 350 Restarting at 0. Send STORE or RETRIEVE to initiate transfer.
[R] (22:14:03) STOR foo.nfo
[R] (22:14:03) 550 foo.nfo: Permission denied.
[R] (22:14:03) Transfer Failed

ffxp overwrite:
[22:15:54] [R] Opening data connection IP: xxx PORT: xxx
[22:15:54] [R] STOR foo.nfo
[22:15:54] [R] Connected. Negotiating TLSv1 session..
[22:15:54] [R] 550 foo.nfo: Permission denied.

I haven't seen anything else in my VFS config that could be the result of this output. The only thing left to say for me would be in terms of "wtf"...
I am still able to overwrite the file with a master account tho with this setup, but I guess it's supposed to be like that...

[Zer0Racer]

Okay I think I figured it out.

Yeah I tested with my master account earlier, but it's still a valid point because Overwrite = * !* is removing overwrite rights from everyone, even master accounts.

So I decided to try with a regular account, and what do you know, I got the same error as you. But I quickly found out what was wrong - I uploaded foo.nfo with my master account and then tried to overwrite it with the regular account. DOH! Of course you get Permission denied when you try to overwrite someone else's file. When foo.nfo was uploaded by the regular user, overwriting it worked.

Case closed?

/ZR

[thunk]

Nope, case not closed. As I said, I want users to be able to modify this foo.nfo under any circumstances, thus also make them able to modify the file and overwrite one that another user uploaded. Guess I'll have to wait for Yil now

A setup like Overwrite = */foo.nfo * would clearly be made to make the file foo.nfo overwritable by everyone (*) ..

tuff: a problem that doesn't exist you say?

[PSA9]

I have the most respect for Yil , as he the only one that can fix our ioFTPD problems. I have the next respect for Tuff , as he is the most active scripter for ioFTPD.
Maybe some should do more reading before asking their problems 'THUNK', While people like TUFF should realize just because its not a problem for him, Its a problem for thunk.
Zer0Racer atleast tried to help, and by him helping i learned something from that and Apparently someone wants to know more bout it too! "HOW ABOUT POSTING THAT 70+"

I did a complete new install to where i had to set all settings again in ioFTPD and ioSFV. I am running v6.2.1 with: ioSFV 1.56 Modified on Windows Vista Ultimate x64. Vista x64 is the least used OS to test ioFTPD. i couldn't upload any files unless was from a master acount. and if u guys would go back and read this post u will probally see the answer u looking for. why am i here saying all this? to help Zer0Racer find the problem to help thunk! and then next time someone has a similar problem he know where to look for the problem. Zer0Racer, Tuff, and Thunk let me inform something Yil has taught me. Zer0Racer said it works with Master accounts. well their is one major thing different from master and non-master accounts. Master accounts ignores this in ioFTPD.ini while non-master accounts use it.

Default_Directory_Attributes = 755 0:0
Default_File_Attributes = 644 0:0

it also says this in ioFTPD 6.2.1 ioFTPD.ini file, The default is to give everyone just read access to all files and directories and set the default owner of files to the ioFTPD account.
well if that is true, Zer0Racer's answer was correct for all master and non-master accounts, but until that is changed to at worst 777 u are not going to be able to edit another users file like thunk wants!

[PSA9]

Now Tuff while i am saying this, i had a request for your ioSFV which u didn't feel was needed! Its just u ask to not modify your script. I modified it and hope that is ok with u? but just to say it may have been useful to some while others it wouldn't. so i asked to see if others would like. on a FTP topsite, the request would be useless, while on a home FTP site it can be very useful. i do both so i do know! Running a FTP on a Computer used in a Streaming environment my request is highly used, so i know how thunk feels bout his problem.

My ioSFV 1.56 Modified adds for my streaming enviroment needs. 99.9% of the time a mp3 is .bad is when programs like Windows media player edits the tag info when the song is done. this has no effect on the song itself but it will make the mp3 not sfv anymore. while true scene members like me really care about getting the orginal one that does sfv, a normal friend visting your home would look at u crazy if u tried to explain that. so when people are at u home and streaming music u have two options for .bad files. #1 rename the .bad files so they work, or #2 the easiest way is to set the ftp and streaming box, like say Xbox Media Center, etc, to the same paths. have ioSFV rename .bad files to .bad except for the files u dont want to end in .bad like say .mp3 etc. so instead of a .bad .mp3 being .mp3.bad i have it set to .mp3-(bad).mp3 and for the people that is going to bash and say that is pointless, its cause u never used a streaming box, burn cds, or have a ipod. with it having a rename as such u can still see the bad files, while also not having to rename .bad files to be able to burn a cd, transfer to ipod, or stream to streaming box. All of which can not read a .bad file. some mp3 releases may take a good while to find one that will sfv but i want to be able to hear the song. so .zip, .rar files do not get effected by my addon to the script, but i have it set to do so for, .mp3 for music, .avi .m2v .mpg for music videos, .pdf for books.

from config if u turn my addon off, ioSFV works as normal, if on, it works for file types u choose and it barely takes any space to add this. say 5 lines at most!

I have added something else though that i wouldn't ask to be added as it really is useless to most! i have a complex FTP which is modified from a topsite way. instead of having xbox, ps2, dvdr, etc in main i have mine set up as such.

_INCOMPLETE
Applications THIS SECTION is mixed with 0-day and ISO
Books THIS SECTION has stuff like game guides
Games THIS SECTION has xbox, xbox 360, ps1, ps2, ps3, psp, dreamcast, pc games, etc.
Movies THIS SECTION has DVDR, xvid, etc
Music THIS SECTION has mp3 only but seperated by genre, ex rap, rock, contry, etc
Music Videos THIS SECTION is setup like mp3

the normal way that incomplete folders gets made is really nice but while i have a very very complex FTP it makes it hard to know everything that is incomplete. so while ioSFV makes a INCOMPLETE folder in the parent dir, it makes the same folders inside the _INCOMPLETE folder at main. the differnce is when u goto the Music dir in say rap, u only see the incomplete mp3 albums in that section, while if u go into the _INCOMPLETE folder at main u see everything that is INCOMPLETE on the site. apps, books, games, movies, music, etc all in a abc order. and when peeps are on the site they can quickly see if they have files to help complete them. like i said for the ones that think its useless atleast ask me to log into my FTP and see if its really nice or useless!!!

[thunk]

Hey PSA9, while tuff has made great contributions to the IO scene, his comment above was quite uncalled for imho. Unlike most posters here, I've had many years experience in ioftpd configging and scripting my own custom shit,.. I actually DO know what the **** I'm talking about. Turns out that this actually can be seen as an ioFTPD 'bug' after all. Besides that, I respect ZR's input in trying to resolve the matter. This one had nothing to do with 'knowing the material' or 'rtfm', I'm just mentioning something I'm having trouble with, so no need to act like a mofo.

Furthermore, I've had my default attributes at 777 since ages, and I've arranged my permissions via VFS setup all along, which works fine.

A setup like Overwrite = */foo.nfo * would really imply that everyone would be able to overwrite a file named foo.nfo in any directory, which is not the case now unless using a master account.

Even with *!, a master account is still able to overwrite files..

[Zer0Racer]

Originally Posted by thunk

A setup like Overwrite = */foo.nfo * would really imply that everyone would be able to overwrite a file named foo.nfo in any directory, which is not the case now unless using a master account.

Even with *!, a master account is still able to overwrite files..

Yes, Overwrite = */foo.nfo * should imply that everyone would be able to overwrite a file named foo.nfo in any directory. Though with Overwrite = * !* not even the master account can overwrite anything, unless you put an allowing rule above it.

I'm not sure how darkone intended for Overwrite permissions to work. As far as I know, Master accounts (M) and vfs admins (V) have hardcoded rights to modify the vfs, or at least something hardcoded that let them circumvent certain restrictions, as all the hardcoded flags have.

With these rules M and V can overwrite foo.nfo but nothing else:
Overwrite = */foo.nfo *
Overwrite = !*

So at least THAT works. After further testing not even Overwrite = * * gives a regular user overwrite permissions (though users now can overwrite their own files), so I guess something in the source checks against those hardcoded properties of the M and V flag too, not only the Overwrite option in ini.

I guess some changes have to be made to fix this, and preferably changing Overwrite behaviour to work as intended and adding something like OverwriteOwn to reflect the way Overwrite currently works.

/ZR