8000 fix: uploading books on Windows (dev env) doesn't work by astappiev · Pull Request #138 · adityachandelgit/BookLore · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix: uploading books on Windows (dev env) doesn't work #138

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

Merged
merged 1 commit into from
Apr 19, 2025

Conversation

astappiev
Copy link
Contributor

While trying to setup a dev environment on my main PC (Windows), I met with an error.

The error comes from Tomcat or even JDK implementation, because they handle transferTo(File) and transferTo(Path) differently. In the project, you use the Path more often and resolve its child (e.g. in PathService). But here in FileUploadService, transferTo(File) was used.

Some examples:
storagePath is equal to: \forks\BookLore\local\booktitle.epub
storageFile is equal to the same, but on transferTo(storageFile), I received

2025-04-19T17:43:20.998+02:00 ERROR 36180 --- [booklore-api] [nio-8080-exec-6] c.a.booklore.service.FileUploadService   : Error saving file

java.io.IOException: java.io.FileNotFoundException: C:\Users\astappiev\AppData\Local\Temp\tomcat.8080.6568768355172360310\work\Tomcat\localhost\ROOT\forks\BookLore\local\booktitle.epub (The system cannot find the path specified)
	at org.apache.catalina.core.ApplicationPart.write(ApplicationPart.java:119) ~[tomcat-embed-core-10.1.36.jar:10.1.36]
	at org.springframework.web.multipart.support.StandardMultipartHttpServletRequest$StandardMultipartFile.transferTo(StandardMultipartHttpServletRequest.java:269) ~[spring-web-6.2.3.jar:6.2.3]
	at com.adityachandel.booklore.service.FileUploadService.uploadFile(FileUploadService.java:58) ~[main/:na]
	at com.adityachandel.booklore.controller.FileUploadController.uploadFile(FileUploadController.java:27) ~[main/:na]
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[na:na]
	at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:359) ~[spring-aop-6.2.3.jar:6.2.3]
	at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196) ~[spring-aop-6.2.3.jar:6.2.3]

Where we can see the path of the file was resolved to C:\Users\astappiev\AppData\Local\Temp\tomcat.8080.6568768355172360310\work\Tomcat\localhost\ROOT\forks\BookLore\local\booktitle.epub.

Replacing it with transferTo(storagePath) fixes the error, and my files upload without any errors.

I'm not sure if there are any performance with difference between these two methods, it seems like transferTo(Path) reads the file into buffer and writes into another OutputFileStream, while transferTo(File) is doing something else, the implementation is hidden in the JDK, so probably it was more performant as implemented low level. However, I consider this difference such that it can be neglected.

Also in this PR:

  • remove pathBook, as it's not used and probably obsolete because now it's per library.
  • refactor FileProcessingUtils to use fileService.getThumbnailPath to make it consistent and more error resistant

@adityachandelgit adityachandelgit added bug Something isn't working patch Backward-compatible bug fixes or tweaks labels Apr 19, 2025
@adityachandelgit adityachandelgit merged commit edb31b7 into adityachandelgit:develop Apr 19, 2025
@github-project-automation github-project-automation bot moved this to Done in BookLore Apr 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working patch Backward-compatible bug fixes or tweaks
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants
0