teltec / everest Goto Github PK

The PostInstaller doesn't stop the Scheduler service before attempting to create or drop the database.

When dropping the database, it fails saying the database is in use.

It seems to happen only when transferring relatively large files - those that require multipart and take minutes to complete.

Possibly related issue in Connections stuck in CLOSE_WAIT, no way to set SO_LINGER, although the issue specifically refers to the Java SDK.

Maybe we should use a prefix the task names with TELTECBKP (or something else) so we could iterate over all tasks that have this prefix, parse their name or arguments, and check whether the referred backup/restore plan still exists.

1. GlacialList

   Glacial List v1.30

   Written By Allen Anderson
   http://www.glacialcomponents.com

2. Copied content from MSDN

   Microsoft Limited Public License (Ms-LPL)

When closing the Edit Plan window using the X button from the title bar, some properties of the model are not reloaded. It should behave like CANCEL.

During the creation of an S3 bucket, the user is allowed to chose between storage classes, however, if the user selects IA (infrequent access), a Lifecycle rule should be created, but it's currently not.

2015-12-14 17:27:37.8132 WARN Failed Z:\DataCenter\Vmware\LAB Cisco Plus\vCenter\vCenter-flat.vmdk - The difference between the request time and the current time is too large.

See attached log.

PlanExecutor\Versioning\IncrementalFileVersioner.cs:593:Save - BEGIN STEP 2
2015-09-17 13:47:06.4455 ERROR BUG: Failed to insert/update BackupPlanFile => {"Id":null,"BackupPlan":{},"StorageAccountType":1,"StorageAccount":{},"Path":"Z:\Empresa\Gerencia Tecnica\Service Desk\Service Desk\Teltec as a Service\Relatórios\NGFWAAS~$ocedimento Relatório WatchGuard.docx","LastSize":0,"LastWrittenAt":"0001-01-01T00:00:00","LastChecksum":null,"LastStatus":1,"PreviousLastStatus":1,"CreatedAt":"2015-09-17T14:08:58.7765746Z","UpdatedAt":"2015-09-17T14:12:17.6027032Z","PathNode":{},"Versions":[],"IsSaved":false} System.Data.SqlTypes.SqlTypeException: SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

2015-09-17.log

The application needs to map the network shares using the saved credentials before running a backup or restore operation.

While editing a Backup Plan, if you uncheck a parent node (e.g., C:) without expanding it to the depth of the already selected sub-nodes (C:\Users\jardel\Desktop\Teste), it won't remove those sub-nodes (the Teste folder) from the database.

The backup operation doesn't work properly with filenames that contain some unicode sequences (combining characters). For example, 1ª, 0°, etc.
Currently, files containing these characters are not processed by the backup operation.

Reported by Raissa Marcon Constante.

2015-12-14 23:35:16.7888 WARN Failed Z:\DataCenter\Vmware\LAB Cisco Plus\Active Directory\Active Directory-flat.vmdk - A WebException with status SendFailure was thrown.

When handling files that have a path length larger than 260 characters (Windows' MAX_PATH), the following exception is thrown:

[PathTooLongException]: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

The .NET API does not support these long paths because of many reasons - See Long Paths in .NET - While the Windows API supports them, I believe it's nearly impossible to get them to work seamlessly and transparently. We could opt for the \\?\ prefix but it will have other impacts. Quoting the previously referenced article:

First about security, the ?\ prefix not only enables long paths; it causes the path to be passed to the file system with minimal modification by the Windows APIs. A consequence is that ?\ turns off file name normalization performed by Windows APIs, including removing trailing spaces, expanding ‘.’ and ‘..’, converting relative paths into full paths, and so on. The existence of FileIOPermissions in .NET means that we absolutely have to work with normalized paths, or risk exposing a security threat. So we knew that if we wanted to use the ?\ prefix as part of the long path solution, we’d need the ability to normalize these paths as expected.

Another concern is inconsistent behavior that would result by exposing long path support. Long paths with the ?\ prefix can be used in most of the file-related Windows APIs, but not all Windows APIs. For example, LoadLibrary, which maps a module into the address of the calling process, fails if the file name is longer than MAX_PATH. So this means MoveFile will let you move a DLL to a location such that its path is longer than 260 characters, but when you try to load the DLL, it would fail. There are similar examples throughout the Windows APIs; some workarounds exist, but they are on a case-by-case basis.

Another factor, which is considered more of a pain factor, is compatibility with other Windows-based applications and the Windows shell itself, which only work with paths shorter than MAX_PATH (note that the Vista shell attempts to soften this limit, briefly described below). This means that if .NET supports long paths, then we’d let you create files that you couldn’t access via Explorer or the command prompt.

Official documentation can be found in Naming Files, Paths, and Namespaces.

What happens if the user edits a BackupPlan or RestorePlan and changes its storage account?

Currently, the application would need to update all entities that reference the previous stored account (BackupPlan, RestorePlan, BackupPlanFile, RestorePlanFile, BackupedFile, RestoredFile, etc), and it would take dozens of minutes if there are thousands of rows in those tables.

A possible and simple solution would be to create a new join-table (id, plan_id, account_id) to associate plans to storage accounts, and change all references from storage_account_id to the_join_table_id. Doing so will make all entities reference the storage account indirectly, avoiding the need to update them all when the storage account is changed in the plan.