Logs

A client logs through the ILoggerFactory its configuration names (FilesConfiguration.LoggerFactory, as Configuration describes), under categories named after the SDK's classes, all in the FilesCom namespace, such as FilesCom.FilesApiService and FilesCom.Http.RetryPolicy: the usual way for an application built on Microsoft.Extensions.Logging, or a host, and one that configures nothing global. Each client has its own, and MinimumLogLevel sets a level for one client alone. Messages are logged through the client of the operation that logs them; your own code, before and after an operation, including after opening a remote file to write, keeps its own logging. Logging never changes what an operation does: if the factory, IsEnabled or Log throws, that message is lost, and the operation goes on as it would have, with its own result or failure.

A client without a logger factory logs with log4net, under loggers of the same names, as the SDK always has. It logs nothing until your application configures log4net, and then goes wherever your configuration sends it, at the levels you choose.

To enable logging, create a file named log4net.config in the same directory as the application with the contents as shown.

Then, in the application, use that file to configure log4net:

log4net.Config.XmlConfigurator.Configure(new System.IO.FileInfo(System.IO.Path.Combine(System.AppContext.BaseDirectory, "log4net.config")));

The FilesCom logger sets the SDK's level alone, whatever the level of your application's other loggers.

log4net.config

<?xml version="1.0" encoding="UTF-8" ?>
<log4net>
  <root>
    <level value="WARN" />
    <appender-ref ref="console" />
  </root>
  <logger name="FilesCom">
    <level value="INFO" />
  </logger>
  <appender name="console" type="log4net.Appender.ConsoleAppender">
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%date [%thread] %-5level %logger - %message%newline" />
    </layout>
  </appender>
</log4net>

Log Levels

ERROR: a request or transfer that failed, by its exception's type and HTTP status.
WARN: cleanup that failed, such as deleting a temporary file, which never changes an operation's outcome.
INFO: each API request, by its method and resource, such as PATCH /users; each retry, with its reason and wait; each upload part request; and how clients are set up.
DEBUG: the details: each API request's full address and body, each API response's body, every failure with its exception, and how uploads choose their part sizes and concurrency.

Levels above DEBUG omit request and response paths, queries, bodies, error text, signed storage addresses and credentials. DEBUG logs full details for troubleshooting, including request and response bodies. Request bodies can contain passwords and other secrets you send. File bytes are never logged. Enable DEBUG only where the logs are protected.