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

Add --dry-run option. #3

Closed
ghuls opened this issue Aug 5, 2020 · 4 comments
Closed

Add --dry-run option. #3

ghuls opened this issue Aug 5, 2020 · 4 comments

Comments

@ghuls
Copy link

ghuls commented Aug 5, 2020

It would be nice to have a --dry-run or -l (--list) option that would just show how files would be renamed, so it is fast to check if -f will do the job the user wants.

$ unf ---dry-run -r My\ Files/ My\ Folder
rename 'My Files/Passwords :) .txt' -> 'My Files/Passwords.txt'
rename 'My Files/Another Cool Photo.JPG' -> 'My Files/Another_Cool_Photo.JPG'
rename 'My Files/Wow Cool Photo.JPG' -> 'My Files/Wow_Cool_Photo.JPG'
rename 'My Files/Cool Photo.JPG' -> 'My Files/Cool_Photo.JPG'
rename 'My Files/' -> 'My_Files'
rename 'My Folder' -> 'My_Folder'
@io12
Copy link
Owner

io12 commented Aug 6, 2020

Thanks for the issue. This is a good idea, but the collision resolution might make it hard to implement. For example, if the contents of a directory are a_001.txt a_001)).txt a_002))))).txt, renaming the files will create a collision, and unf checks for collisions as it's renaming. To handle --dry-run, unf would need to scan the files, load them into a virtual file tree, and rename them inside the virtual file tree. The unit tests handle this by creating file trees in a temporary directory, although that's probably not the ideal behavior for --dry-run. Probably the solution is to make the renaming only run on virtual filesystems, but have a function to actually apply the renames.

@ghuls
Copy link
Author

ghuls commented Aug 6, 2020

Could you not use a HashSet to store all files (and dirs) in a certain directory and modify the HashSet by removing the key with the old filename with an old name and add a new tilename with the new key while checking that that file does not already exist in the HashSet. For the real file renaming, the old code should be used (as new files can appear while renaming others).

@io12
Copy link
Owner

io12 commented Aug 6, 2020

Could you not use a HashSet to store all files [...]

I think there are cases where the ordering of the files changes what renames happen, and read_dir() probably won't return filenames in the same order as HashSet::iter(). Probably some other datatype like a Vec or BTreeSet and enforcing sorting would work, though.

For the real file renaming, the old code should be used (as new files can appear while renaming others).

Yeah, this is a good point.

@io12
Copy link
Owner

io12 commented Aug 10, 2020

Fixed in 2.1.0. I ended up using an in-memory filesystem library.

@io12 io12 closed this as completed Aug 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants