[TIMOB-28146] Android: Ti.Filesystem.File rename() should support an absolute path in same directory
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2020-10-22T22:23:16.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 9.3.0 |
Components | Android |
Labels | android, engSchedule, file, filesystem, parity |
Reporter | Christopher Williams |
Assignee | Joshua Quick |
Created | 2020-09-18T17:21:23.000+0000 |
Updated | 2020-10-22T22:23:16.000+0000 |
Description
This one shows up in our unit tests for Ti.Filesystem.File.rename. If we attempt to rename a file by passing in an absolute path for the destination (as a sibling of the original file path), the rename fails.
See: https://github.com/appcelerator/titanium_mobile/blob/master/tests/Resources/ti.filesystem.file.test.js#L619-L642
I assume the issue is related to the underlying code which constructs the destination file: https://github.com/appcelerator/titanium_mobile/blob/master/android/titanium/src/java/org/appcelerator/titanium/io/TiBaseFile.java#L359-L360
[~cwilliams], but should [rename()](https://docs.appcelerator.com/platform/latest/#!/api/Titanium.Filesystem.File-method-rename) accept an absolute path? Our docs for argument
newname
suggests it should only accept a file *+name+* and not a file *+path+*. And we already have a [move()](https://docs.appcelerator.com/platform/latest/#!/api/Titanium.Filesystem.File-method-move) method with an appropriately namednewpath
argument. Granted, natively a file rename/move is the same thing, but our Titanium APIs makes a distinction. I don't mind us adding support, but since we correctly follow the docs, I would say this is an "improvement" request and not a "bug".PR (master): https://github.com/appcelerator/titanium_mobile/pull/12143
FR Passed for this part of the PR.
Verified the fix with SDK 9.3.0.v20201022111908. Closing.