You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After restoring a file from Deleted files, the restore succeeds and the file is correctly placed back in Personal files. However, opening the restored file immediately afterwards causes the Files app to navigate back to Deleted files (breadcrumb such as Deleted files / Documents), even though the file no longer exists there.
In some cases, even newly uploaded files under Personal files subsequently open in the trash view until the page state is refreshed.
This appears to be a stale Files UI state (path, file id or navigation context) after restoring an item from the trash rather than a failed restore.
Steps to reproduce
Create a folder (e.g. Documents) in Personal files.
Upload a .docx file to that folder.
Delete the folder.
Open Deleted files.
Restore the folder.
Verify that the folder is back under Personal files.
Open the restored .docx file.
Update: we disabled Full Text Search to rule it out:
files_fulltextsearch
fulltextsearch
fulltextsearch_elasticsearch
Behaviour is unchanged (restore still navigates to Deleted files when opening the file). So this does not appear related to FTS.
Also note: instance is on 33.0.0 (config above).
Expected behavior
After restoring a file or folder, opening the file should remain in Personal files.
The Files app should not navigate back to Deleted files once the item has been restored.
The breadcrumb and navigation context should reflect the restored location.
Nextcloud Server version
33
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 31 to 32)
Are you using the Nextcloud Server Encryption module?
Bug description
After restoring a file from Deleted files, the restore succeeds and the file is correctly placed back in Personal files. However, opening the restored file immediately afterwards causes the Files app to navigate back to Deleted files (breadcrumb such as Deleted files / Documents), even though the file no longer exists there.
In some cases, even newly uploaded files under Personal files subsequently open in the trash view until the page state is refreshed.
This appears to be a stale Files UI state (path, file id or navigation context) after restoring an item from the trash rather than a failed restore.
Steps to reproduce
Update: we disabled Full Text Search to rule it out:
Behaviour is unchanged (restore still navigates to Deleted files when opening the file). So this does not appear related to FTS.
Also note: instance is on 33.0.0 (config above).
Expected behavior
Nextcloud Server version
33
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 31 to 32)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
{ "system": { "config_is_read_only": false, "appstoreenabled": true, "trusted_domains": [ "***REDACTED***" ], "forwarded_for_headers": [ "HTTP_X_FORWARDED_FOR" ], "htaccess.RewriteBase": "\/", "default_phone_region": "NL", "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "overwrite.cli.url": "https:\/\/***REDACTED***", "proxy": "***REDACTED***", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbport": "3306", "dbtableprefix": "oc_", "mysql.utf8mb4": true, "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "secret": "***REMOVED SENSITIVE VALUE***", "installed": true, "mail_smtpmode": "sendmail", "mail_sendmailmode": "smtp", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "memcache.local": "\\OC\\Memcache\\APCu", "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 16379, "ssl_context": { "local_cert": "***REDACTED***", "local_pk": "***REDACTED***", "cafile": "***REDACTED***", "verify_peer_name": true } }, "log.condition": { "apps": [ "admin_audit" ] }, "log_type": "syslog", "logfile": "", "loglevel": 2, "syslog_tag": "Nextcloud", "log_type_audit": "syslog", "syslog_tag_audit": "Nextcloud-audit", "logfile_audit": "", "skeletondirectory": "\/data\/appdata_skeletondirectory", "theme": "", "simpleSignUpLink.shown": false, "maintenance": false, "version": "33.0.0.16", "maintenance_window_start": 1, "twofactor_enforced": "true", "twofactor_enforced_groups": [], "twofactor_enforced_excluded_groups": [], "enable_previews": false, "forbidden_filename_characters": [ "?", "<", ">", ":", "*", "|", "\"" ], "integrity.excluded.files": [ ".htaccess", "resources\/config\/ca-bundle.crt" ], "proxyexclude": [ "***REDACTED***", "***REDACTED***" ], "overwriteprotocol": "https", "serverid": 1, "server_id": 1 } }List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info