microsoft
Downloaded file creation/modified dates randomly get set to current timestamp
Storage Explorer Version
1.38.0
Regression From
No response
Architecture
x64
Storage Explorer Build Number
20250408.1
Platform
Windows
OS Version
Windows 11
Bug Description
When downloading files, most files are created in my local filesystem with the correct date/time as shown in ASE, but some randomly get touched with the current date/time instead.
Steps to Reproduce
- Launch Storage Explorer
- Navigate to a File Share
- Download a set of files
- Compare the creation/modification timestamp shown in ASE with the files downloaded to your local file system.
Actual Experience
Most files have the correct date/time, but some are instead created with the current date/time.
Expected Experience
The timestamps for files downloaded should always match what is shown in ASE.
Additional Context
No response
@richardtallent-erm I don't think this is a Storage Explorer issue only. Are you able to download your files from the Azure Portal or using AzCopy? Do you observe similar behavior with the timestamps?
My (limited) understanding is the SMB protocol has limitations such that timestamps are not always preserved, so the OS stamps them with the current time.
I'd be very surprised if ASE uses SMB, it should be using REST endpoints to download.
In Azure Portal, I can't see or sort by date, so pretty hard to test there. However, I did download two files from Portal, one that came through ASE correctly and another that got touched, and when downloading from Portal, both came with the incorrect (current) timestamp.
Some of the filenames are rather long, but there's no difference in filename length between the successful and unsuccessful ones. None have ACLs, and all were placed in storage by the same web app at the same time (using a mapped folder).
Since the app shows the correct date but creates the file locally with the wrong date, I'm still leaning toward this being a client-side issue.
I have often observed on multiple platforms that dates for files downloaded from a variety of locations just using a browser are not always preserved. The OS fills their creation date with the date that they were downloaded instead. For example, I download builds of Storage Explorer completed hours or even days ago, but after downloading to a test Mac machine, the downloaded file has a creation date of the time it was downloaded.
Perhaps part of the problem with what you're seeing in Azure vs locally is Azure tracks metadata separately from the underlying file system used by the file share. Azure's metadata is what you see if you query a file's properties, but those file properties aren't the same as the file system's and don't come with the file data itself.
Storage Explorer does use REST to list files from file shares. Storage Explorer uses AzCopy to transfer files with Azure File Storage (which also uses REST calls underneath). AzCopy is a command line tool that handles blob and file transfers. When you start a transfer, Storage Explorer lets you copy the exact command that it uses to invoke AzCopy. The AzCopy executable that comes with Storage Explorer can be found in resources/app/node_modules/@azure-tools/azcopy-win64/dist/bin. If you use AzCopy directly, do you still find disparities in the dates?
If you use the Storage Browser in the Portal, you should be able to see at least Modified times:
Closing due to inactivity. If this still an issue, please reply with answers to the above questions, and we can revisit.