Log options [request]

[SamePaul]

1. Option to log Delete attempts and successful deletions. Currently these actions are almost completely ignored. You can see POST but cant' know which file was attempted to delete.
2. Also log filesystem errors. For example if HFS has no access to specified location in VFS or failed to delete something or whatever else. Log these errors too with number and code-to-text translation (the one that comes from FormatMessage or maybe Pascal has own translation)
2. Option to have different set for screen and file logging. For example, I would keep on screen only important things like downloads, uploads, deletions. And in logfile store detailed information about request.

Thank you

[r][m]

I think a log entry for completed Delete would be useful. I have no need for attemps.
I may not understand point #2, but we already have 401, 403 ect, logged. Excluding
with no log, Log what, and filters in properties eliminates undesirable log entries for me.
Second point #2, As long as its an option, maybe.

Something I'd like to see added to the log, is Events [ /~login ] - add to log - append - %ip%
 - {.header|referer.} - {.header|user-agent.}
That would generate a once per log in, list of who, what they are using and where they came from.

Rejetto
I think it might be a "good thing" to add a forum topic for log related things.

[rejetto]

1. you are right. i just overlooked logging when i implemented deletion.

2. we should carefully choose what errors should be logged. i don't understand your examples. can you describe a case?

3. it's ok, but i would not spend time on it for now, until we get a totally new options panel.
in the while, you can get a similar results by using [events] and {.add to log.}

[rejetto]

Something I'd like to see added to the log, is Events [ /~login ] - add to log - append - %ip%
 - {.header|referer.} - {.header|user-agent.}
That would generate a once per log in, list of who, what they are using and where they came from.

if you want to log when people uses the "login" but not when they log in by clicking a protected resource, you can already do it.

I think it might be a "good thing" to add a forum topic for log related things.

this is a forum topic. did you mean a board?

[r][m]

if you want to log when people uses the "login" but not when they log in by clicking a protected resource, you can already do it.

In hfs.events? I find no reference with forum search, nor in wiki?
Nothing I tried works. Could you explain? Or even better post something that does.

this is a forum topic. did you mean a board?

I guess.
There seems to be posts regularly about log related things.
If people would use it, that would make info a little easier to find, maybe.

[SamePaul]

2. we should carefully choose what errors should be logged. i don't understand your examples. can you describe a case?

It's usually bad practice when application has problems and doesn't inform user in any way about this.
In this specific case I mean folders referenced in VFS but absent or inaccessible for HFS. Popping up dialog boxes "Aaaah! I can't access folder ..." is not nice idea, but write in the log "Folder .... referenced in VFS but is inaccessible". Or even better "Error access 'object.name': [1234] <Descriptive system error message>".
But I agree this stuff is not emergency and surely can wait. Actually you even don't have to implement it at all - it was just request, but as author you are free to agree or disagree

[rejetto]

if you want to log when people uses the "login" but not when they log in by clicking a protected resource, you can already do it.

In hfs.events? I find no reference with forum search, nor in wiki?

i wanted to know you needed it.
this is untested

[request]
{.if|{.%url% = /~login.}|{:{.add to log|{.header|referer.} - {.header|user-agent.}.}:}.}


splitting to another board has not only pros, but also cons. i try to do it when i'm sure we need it.

[r][m]

And the path is obvious when someone who knows lights the way.
It works great.  But the solution would have never occured to me.
Thanks

splitting to another board has not only pros, but also cons. i try to do it when i'm sure we need it.

It was just a thought, perhaps not a child board, but maybe a sticky topic (I think its called?)

[rejetto]

the scripting system is very powerful, but also very unfriendly.
i don't believe everyone will make his own script, i just hope most people know someone skilled and willing that will do it.
while computers don't understand our needs...