FlashFXP Forums - View Single Post

Yil · 04-02-2007, 07:46 PM

Tuff: looks like that's the ticket. The ascii encoding isn't defined for >127. That appears to be proper TCL behavior as it's in the official distribution that way and the only reason nobody noticed before was the entire encoding directory wasn't included with ioFTPD releases so without a proper encoding file it just left everything alone...

Carpo: great info on script compatibility. Just for kicks try reverting to the old minimal TCL dir to see if that affects anything. The encoding issue may be affecting more than just iputs.

Tuff: Grr, I must have broken something when trying to determine if the move was a move or a rename when I fixed it to handle network shares (I hope). And yes, you guessed the behavior for a filesystem move. Create the new dir as an NTFS hidden dir, start copying everything over recursively deleting the source only after a successful copy. This prevents any permission race condition because ioFTP won't let you access a hidden NTFS dir and thus you can't enter any directory in the process of being copied. The fact that it died isn't good news either, so perhaps I'll have to test larger sized moves...

oldhouse: There are lots of permissions in ioFTPD: First, you must have access via the VFS section of ioFTPD. It appears that you have done that. Then you must have file/directory permission. Try creating a directory FOO, and using "site chmod 777 FOO". Users should be able to upload to that directory now. You may find setting the default directory permission to 775 is what you want so that people in the same group can upload but others can't. 755 allows only the owner to upload and 777 allows anyone. With appropriate VFS settings in ioFTPD that may be OK, but for the default I chose the more restrictive setting and you can then open up the sections you want. New dirs inherit the parents permissions so once you open up a tree it should stay open. I'm pretty sure this is a pure configuration issue on your part but I've been wrong a lot today so can you cut/paste a LIST -al of the directory showing the permissions and verify the flags of the user who can't upload? And if chmod fails any error you get?

04-02-2007, 07:46 PM
Yil Too much time... Join Date: May 2005 Posts: 1,194	Tuff: looks like that's the ticket. The ascii encoding isn't defined for >127. That appears to be proper TCL behavior as it's in the official distribution that way and the only reason nobody noticed before was the entire encoding directory wasn't included with ioFTPD releases so without a proper encoding file it just left everything alone... Carpo: great info on script compatibility. Just for kicks try reverting to the old minimal TCL dir to see if that affects anything. The encoding issue may be affecting more than just iputs. Tuff: Grr, I must have broken something when trying to determine if the move was a move or a rename when I fixed it to handle network shares (I hope). And yes, you guessed the behavior for a filesystem move. Create the new dir as an NTFS hidden dir, start copying everything over recursively deleting the source only after a successful copy. This prevents any permission race condition because ioFTP won't let you access a hidden NTFS dir and thus you can't enter any directory in the process of being copied. The fact that it died isn't good news either, so perhaps I'll have to test larger sized moves... oldhouse: There are lots of permissions in ioFTPD: First, you must have access via the VFS section of ioFTPD. It appears that you have done that. Then you must have file/directory permission. Try creating a directory FOO, and using "site chmod 777 FOO". Users should be able to upload to that directory now. You may find setting the default directory permission to 775 is what you want so that people in the same group can upload but others can't. 755 allows only the owner to upload and 777 allows anyone. With appropriate VFS settings in ioFTPD that may be OK, but for the default I chose the more restrictive setting and you can then open up the sections you want. New dirs inherit the parents permissions so once you open up a tree it should stay open. I'm pretty sure this is a pure configuration issue on your part but I've been wrong a lot today so can you cut/paste a LIST -al of the directory showing the permissions and verify the flags of the user who can't upload? And if chmod fails any error you get?