Re: [Proftpd-user] .in. Files Not Cleaned Up Properly - HiddenStores

Hi,

Thanks for your time and reply.

Sorry I am not fully getting your point.

We have DeleteAbortedStores set to on, which means those files should be 
getting deleted, but they're not.

We've also haven't been able to reproduce the problem, blocking the IP 
while the transfer is in progress, or killing the FTP process on the 
client side while uploading, none of those has caused the .in.FILENAME 
file to stay and it gets deleted.

So we're trying to establish if this is a bug whereby under certain 
use-case the .in.FILENAME file gets left behind hanging around and never 
going away, and the consequence is it stops the user from ever uploading 
the file with exact same name again (FILENAME) until the .in.FILENAME 
has been deleted.

Am I missing something here?

[email protected]

On 29/01/2021 13:32, Matus UHLAR - fantomas wrote:
> On 28.01.21 17:07, [email protected] wrote:
>> Sure thing, here you go:
>
>> <Global>
>>     AllowForeignAddress    on
>>     DefaultRoot    ~
>>     AllowOverwrite    on
>>     AllowRetrieveRestart    on
>>     PassivePorts    59000 60050
>>     RequireValidShell    off
>>     RootLogin    off
>>     ShowSymlinks    on
>>     HiddenStores on
>>     TransferLog /var/log/proftpd/proftpd-transfer.log
>>     DeleteAbortedStores on
>> #<Directory /some/location/*>
>> #        HideFiles 
>> (\.wmv|\.mp4|\.avi|\.mov|\.mkv|\.3gp|\.vob|\.asf|\.aiff|\.flv|\.f4v|\.f4p|\.f4a|\.f4b|\.ts|\.mpg|\.mpeg|\.ogv|\.ogg|\.ram|\.rv|\.rv9|\.webm)$
>> #</Directory>
>> <Limit SITE_CHMOD>
>> DenyALL
>> </Limit>
>> </Global>
>
> well guess all those should apply.
>> I am confident the server hasn't crashed, as in hardware/actual 
>> server dying or anything like that, this is a production server with 
>> monitoring etc. on it...
>
> I means that the handling server process crash, not OS or proftpd daemon
> itself.
>
> but we'll assume those are results of connection failures or drop, not a
> result of ABOR command:
>
> http://www.proftpd.org/docs/directives/linked/config_ref_DeleteAbortedStores.html 
>
>
> The DeleteAbortedStores directive controls whether ProFTPD deletes 
> partially
> uploaded HiddenStores files if the transfer is stopped via the ABOR 
> command
> rather than a connection failure.
>
>>> On 28.01.21 11:22, [email protected] wrote:
>>>> However I have noticed on our FTP server, we have tons of 
>>>> .in.FILENAME files hanging around on different user directories, 
>>>> all with 0 KB filesize. Also, some of these go back to as old as 
>>>> 2019, throughout 2020... i.e. they're genuinely not in-progress 
>>>> upload files.
>
>
>> On 28/01/2021 16:17, Matus UHLAR - fantomas wrote:
>>> these can be nested in <If* blocks, we need whole config
>>> (can be redacted).
>
>>>> Any idea why this is? What's the correct way to handle this? Do we 
>>>> need to manually delete these files, and if so, why are they not 
>>>> deleted by proftpd? Thanks for any info.
>>>
>>> it can also happen if ftp server crashes.
>
>
>

_______________________________________________
ProFTPD Users List   <[email protected]>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html