Opened 6 years ago
Last modified 5 years ago
#11573 new Bug report
Files deleted while "confirm replacement" is given
| Reported by: | Bernard TREMBLAY | Owned by: | |
|---|---|---|---|
| Priority: | high | Component: | FileZilla Client |
| Keywords: | Cc: | ||
| Component version: | 3.32.0 | Operating system type: | Windows |
| Operating system version: | win10 x64 fully updated |
Description
Hi,
This comes with new (very last news version).
When you uses this :
1- upload a new version of a file with a different name.
2- after upload : rename the file and give the name of the file which is to be replaced
Before, with previous version, you get :
1- A panel to confirm (existing file with same name : replace)
2- Replacement
3- (in previous-previous) the position into the list was not changing
Now, new ( 3.32.0) you get :
1- A panel to confirm (existing file with same name : replace)
2- Both files are deleted, this most of time (there are conditions which produce the normal - old - behavior, but I could not find exactly the conditions.
Note :
- that when this occurs we have two refreshes (since-prev-prev : I have not the version id) of screen while before we were getting this refresh just once.
- with the "just before version" the refresh was not clean because we had, as told, two displays and at the end the user was reaching the top of the list and had to go back manually to the position of the file changed to verify.
- now when it functions normally the file is replaced and focus stays on the file (generally for the two files : I name the new updated with a name so that it will be displayed just before the file to replace into the list). I think that the second display corresponds to the "delete all" invalid phase.
Best regards
Trebly
Note:
See TracTickets
for help on using tickets.
Hi,
Still remains on 3.38.1
When you perform :
1- load an update file with different name
2- Rename with the current name of the file to execute
3- after display of "confirm" panel and answer "yes"
A first display shows the new file deleted and the alone remaining (current name) for a short moment.
Then a reset is done and the right current file is deleted.
The turn around is to never use this capability :
1- rename the current file which will become old (or delete it)
2- load the new updated
3- rename the new updated for current name
4- if needed delete or move ancient file to ".old" directory
This is much more longer, complex and boring, not sure process for a commonly repeated operation which fails quite once on two