Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Godot 4.4 get_modified_time fails on Windows system #103581

Closed
jospic opened this issue Mar 4, 2025 · 9 comments · Fixed by #103622
Closed

Godot 4.4 get_modified_time fails on Windows system #103581

jospic opened this issue Mar 4, 2025 · 9 comments · Fixed by #103622

Comments

@jospic
Copy link

jospic commented Mar 4, 2025

Tested versions

  • Reproducible in Godot 4.4 stable version

System information

Windows 10 - v4.4.stable.official [4c311cb]

Issue description

FileAccess.get_modified_time(file_path) returns "0" on Windows system.

Steps to reproduce

func get_file_modification_time(file_path: String) -> String:
	
	if FileAccess.file_exists(file_path):
		var timestamp = FileAccess.get_modified_time(file_path)    # seems to fail on Windows platform
		var date_time = Time.get_datetime_dict_from_unix_time(timestamp)
		
		var formatted_time = "%02d/%02d/%04d %02d:%02d:%02d" % [
			date_time.day, date_time.month, date_time.year,
			date_time.hour, date_time.minute, date_time.second
		]

		return formatted_time
	else:
		return "File not exists!"

Minimal reproduction project (MRP)

See "Steps to reproduce"

@matheusmdx
Copy link
Contributor

Can't reproduce on my end. When you did the first test was checking if file exists? Any file returns 0? When returns 0 means an error occurred (most of the cases an invalid path).

@bruvzg
Copy link
Member

bruvzg commented Mar 4, 2025

What kind of files are you checking? If you are trying to get modification time of the file with res:// path in the exported project, it won't work since it's part of PCK, not a real file. And PCK does not store modification time (it's read-only).

It should return 0 if:

  • path is invalid.
  • path is directory, not file.
  • you do not have read permissions for the file.
  • time is set to value before beginning of Unix epoch (Windows is counting time since January 1, 1601).
  • it's not supported by the file system.

@jospic
Copy link
Author

jospic commented Mar 4, 2025

The same script works without issues on Godot 4.3 official version.

File exists and path Is an absolute path with a file at the end (in that case a SQLite file)

@jospic
Copy link
Author

jospic commented Mar 4, 2025

Can't reproduce on my end. When you did the first test was checking if file exists? Any file returns 0? When returns 0 means an error occurred (most of the cases an invalid path).

The first check, file exists, pass without problem. Path Is valid and real.

@Calinou
Copy link
Member

Calinou commented Mar 4, 2025

@jospic Can you try following the same steps on 4.4 dev/beta/RCs to determine when the regression started? You can download them here.

@jospic
Copy link
Author

jospic commented Mar 5, 2025

@jospic Can you try following the same steps on 4.4 dev/beta/RCs to determine when the regression started? You can download them here.

Hi @Calinou,
ok, I did various tests starting from dev versions up to all the release candidates. I verified that dev 1 does not show the issue, while it is present from dev 2 onwards.

It might be related to the pull "Reduce code duplication in FileAccess ([GH-92167]" from DEV 2 Changelog (#92167)) ?

Thanks in advance.
-j

@bruvzg
Copy link
Member

bruvzg commented Mar 5, 2025

Most likely it is related to #74830, but not sure why it's not working in your case. The only reason I can think of is, the file is already opened for writing with exclusive access, which might be interfering with the CreateFileW.

@jospic
Copy link
Author

jospic commented Mar 5, 2025

Most likely it is related to #74830, but not sure why it's not working in your case. The only reason I can think of is, the file is already opened for writing with exclusive access, which might be interfering with the CreateFileW.

I don't know, but I don't think it's due to some blocking problem on the specific file. I have tested on many different files and I confirm that the dev 1 build does not show any problems, unlike the dev 2

@bruvzg
Copy link
Member

bruvzg commented Mar 5, 2025

I don't know, but I don't think it's due to some blocking problem on the specific file.

Blocking definite is an issue, and easily reproducible one. It's possible that there's something else as well, but I can't reproduce it with any other file.

@Repiteo Repiteo added this to the 4.5 milestone Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants