Trace where a file travelled and what changed along the way
See where a file started, which devices it passed through and when it reached the final server. Search for the file in INNORIX Studio, follow the transfer runs attached to it, and you have the timings, the route and whether each stage succeeded or failed. Even when several devices hold a file with the same name, you can trace it by comparing the real transfer records alongside the file information.
Cómo se construye
- Line up the devices and the transfer records.
In Studio Devices, confirm the devices involved, and in Flows and Runs confirm that a transfer including the file you want to trace actually ran.
- Search for the file.
Search by filename from the Dataset or the file search screen and, if you need to, narrow the results by source device, path or modified time.
- Select the file in the results.
If several files share the name, compare the information provided — device, path, size, time — and select the one you want to investigate.
- Review the route in File Journey.
Review the transfer stages from the source device through any intermediate processing server to the final server, the time each stage ran, the result, and the Run behind it.
- Investigate the stage that went wrong.
Move to the Runs detail for the segment where a delay, failure or retry happened, review the result and, if needed, re-verify the source and target paths for that file.
Dónde se usa
- Confirming how a quality report was delivered
Check whether inspection results produced at a factory reached the head office analysis server by way of the central server, and find any segment where they went missing.
- Investigating when a batch result arrived
Compare the run records to see when a file exported from ERP reached the downstream processing server and the archive server, and investigate the cause of a delay.
- Verifying a multi-stage distribution
On a transfer that runs head office → regional server → branch server, see stage by stage why the file never arrived at one branch.
- Gathering transfer evidence for an audit
Confirm the transfer times, the source and destination devices, and the related run records for a given file, and use them as the basis for audit material. What can actually be evidenced depends on the log retention policy.
- Resolving confusion from identical filenames
When
production-report.csvexists on several devices, compare paths, times, file metadata and Run records to establish which transfer each file belongs to. - Understanding the retry history after a failure
Trace the jobs re-run after an initial transfer stopped, to see which segment failed and when it finally completed.
- Confirming file movement during a cloud migration
Confirm which job transferred a file moved from an internal server to object storage, and compare the source and destination records.
Guías de uso
Preguntas frecuentes
Is there a way to trace which server a file started on and where it was sent?
INNORIX Studio runs file transfers between devices as Flows and Runs, and those run records can be reviewed. File Journey can be designed as a feature that links those records around a file to show its route. What file-level tracing is actually provided has to be confirmed against the product version and the record retention settings.
Can I see the whole route of a file delivered from server A through B to C?
Where the A → B and B → C transfers that INNORIX carried out and recorded can be associated with the same file, the run record for each stage can be reviewed. If the two jobs ran separately, or an intermediate system renamed the file, additional identifying information may be needed.
Can I see who transferred which file and when?
The transfer run records and audit information in Studio show what was recorded — the job time, the source and target devices, who ran it. How far the actor is identified can vary with how the job was run — by a user, on a schedule, through an API — and with the audit settings.
Are files treated as the same file, and their routes linked, just because the name matches?
No. The same filename can carry different contents or come from a different source. Reliable file tracing means checking the source path, the file size, the modified time, the associated Run information and, where provided, a hash or unique identifier. The histories of two different files must never be linked on the name alone.
Can I see what changed inside a file, including earlier versions?
Transfer records focus on when and where a file moved. That is different from version control, which stores and restores how an external application changed the contents of a file and what those contents were before. How far change history goes depends on the metadata recorded and on whether separate version control is supported.
Can failures and restarts during a transfer be traced too?
Runs in INNORIX shows the execution states actually recorded, including failures, interruptions and retries. Which attempts are linked at the file level, and how much recovery detail is shown, has to be confirmed against the product features.
Are files moved in the past with FTP, SFTP or another program traced automatically?
An external transfer that INNORIX did not run or record cannot be assumed to link into the same transfer history automatically. Existing system logs have to be retained or integrated separately, and whether external logs can be brought into File Journey has to be confirmed.
What records should be kept for an audit or an incident investigation?
What matters is retaining the transfer time, who ran it, the source and target devices and paths, the file identifying information, the success or failure state and the retry records. Log retention periods, access rights, tamper protection and export have to be reviewed separately against your audit requirements.