Problem with dir attributes used over several dir levels

[mantonio1965]

Hi,

i seem to not understand if and how to define different Directory_Attributes for the different directory levels i use on my server. In ioFTPD.ini i changed the Default_Directory_Attributes from 777 to 755 and encoutered the server to sometimes create directories with dir attribute 7 only and the files also with one digit. Can't remember anymore, which one since i immediately chmodded these directories with flashfxp.

But is there generally a way to define different attributes for different directory levels?

[Yil]

A newly created directory inherits permissions (rwx stuff) from their parent and owner/group from the creator. The Default_Directory_Attributes is only used for a directory that doesn't have any owner/permission information at all which means it was likely created outside of the server and doesn't have a .ioFTPD file in it.

Please note that the R attribute for directories acts like R and X as far as unix would be concerned. Use private dirs if you want weird behavior where you would only have one of those attributes. This frees up the X bit which was intended to be used in archiving scripts so you could lock dirs from being archived and/or auto-wiped for space.

[brackebuschtino]

A newly created directory inherits permissions (rwx stuff) from their parent and owner/group from the creator. [...] likely created outside of the server and doesn't have a .ioFTPD file in it
Well, the dirs mentioned all do contain the mentioned file. And so i wonder why ioNiNJA(latest version) changes the directory attributes to 007 after applying the "site rescan this" command. The related directory resides at level 6 beginning from root and all of its parent directories have attribs 755 and are owned by the same user:group.

How come this strange attribs result?

[mescal1n]

Well, the dirs mentioned all do contain the mentioned file. And so i wonder why ioNiNJA(latest version) changes the directory attributes to 007 after applying the "site rescan this" command. The related directory resides at level 6 beginning from root and all of its parent directories have attribs 755 and are owned by the same user:group.

How come this strange attribs result?

I have exactly the same problem... Can anyone else resolve this?

@brackebuschtino, could you fix the problem?

[Yil]

Does this only happen with 'site rescan this' ? Have you applied the fix to 'site rescan' for the latest version of ioNiNJA?

Can you examine the filenames/pathnames and see if any of them have spaces or other weird characters like {[(' in them? I took a quick look at ioNiNJA and it does change permissions via [vfs write] in a few places and it just occurred to me that [vfs write <filename> 0 0 744] might somehow be ending up as 007 or something. I can't see why that would happen but it's the only thing I can think of...

[mescal1n]

Thanks for the fast answer. The problem appears in every dir after completing a sfv/release. After complete, the dir gets changed to 007. I've also applied the ioninja lib fix which i was missing somehow, restarted ioftpd... but no change. :(

No spaces or strange characters in the dirnames. No "("... just letters, numbers and dots. But on "site rescan this", the dir attribs get changed from 777 (which I've changed manually before) back to 007 again.

Any more ideas?

Thanks again!

[Yil]

Just double checking you're running io 7.7.3 or 7.7.2 and this is the latest version of ioNiNJA?

The only other option I saw in the ninja config file was this: set ioNJ(complete_lock) 1

That is the default setting, but see if you have it and then try turning it off.

One potential issue I've run across from time to time is the server / scripts aren't very good about validating and reporting on issues with the config files. If you get stray characters, etc it can mess things up and you can't always see them in some editors. You could try extracting a new ioNiNJA.cfg file and see if using the default settings on an upload works before editing it to make it do what you want...

[mescal1n]

I have: "set ioNJ(complete_lock) 0", ioFTPD v7.7.3 and ioNiNJA is latest.

I've checked again for paths and folder names, all fine, no special chars, no spaces.