Renamed x files, failed to rename y files. Why?

Cantello · 2009-08-19 11:25

Hey all!

I like to use ReNamer very much as for me it is a blend of simplicity and power.

Sometimes, though, I fail to understand why RN fails to rename certain files or folders (more folders, actually). It creates the new folder, moves all files over but then fails to delete the old folder. It is not read-only and I work with XP, so none of the Vista issues I have read about.

Can I find the reason somewhere? Logfile or something similar?

Thanks! :-)

Andrew · 2009-08-19 11:52

Are you using PascalScript? AFAIK ReNamer can't delete folders otherwise. Also, while moving, you have to be sure the order is correct, i.e. all the files and folders inside have to be moved out before the outer folder can be deleted.

Cantello · 2009-08-19 11:57

Andrew wrote:

Are you using PascalScript? AFAIK ReNamer can't delete folders otherwise. Also, while moving, you have to be sure the order is correct, i.e. all the files and folders inside have to be moved out before the outer folder can be deleted.

No, no such thing as PascalScript here. Just a translit action to get rid of all the umlauts in my MP§ collection before moving them on a NAS system.

I have simply added all files & folders for renaming, so I don't move anything by hand or by script but ReNamer's renaming actions did it for me.

As for the correct order: Would it help to sort files first in the list?

Stefan · 2009-08-19 16:15

Hi Cantello, welcome.

I never tried what you have done. so i can't say if this should even work.

But generally, if an file/folder can not be deleted/renamed an other process holds hes hand on this folder.
So... did you have WinExplorer pointed to that folder at the time in question????
Or maybe an MP§ player still running?

Cantello · 2009-08-19 18:14

Stefan wrote:

Hi Cantello, welcome

Thanks! :-)

Stefan wrote:

I never tried what you have done. so i can't say if this should even work.
But generally, if an file/folder can not be deleted/renamed an other process holds hes hand on this folder.
So... did you have WinExplorer pointed to that folder at the time in question????
Or maybe an MP§ player still running?.

No, as far as I know, there were no other processes accessing the folder in question. Next time I will check with Unlocker (http://ccollomb.free.fr/unlocker/).

Stefan wrote:

(Tip: Developing and web-hosting costs money, ...maybe you want to spent $1 / 1€ to Denis ?)

Maybe I do, and seeing how much work RN has already saved me, I just donated some Euros to Denis. Keep up the good work Denis! ^_^

narayan · 2009-08-19 20:47

I am guessing the following (but it may not be far off the mark):

Since the renaming is done top-down, all files that are listed BEFORE the folder will get renamed and be placed inside the original folder (which is still not renamed when each of these files are renamed).

When the folder's turn comes, it is renamed. All the files that are in the folder are also effectively "moved" to the new folder; including those files that are yet to be renamed in the ReNamer (i.e., the files that are listed AFTER the folder)..

Now ReNamer takes up the remaining files. It still looks for those files in their old path. But these files have already moved to the new folder, Therefore ReNamer is unable to find them So it reports that it failed to rename those files.

Result: These remaining files will be in the renamed folder, but they will not be renamed.

Furthermore, since ReNamer senses that some files in the original folder could not be renamed, it infers that the folder is not empty. Therefore does not delete it.

OR-
ReNamer itself locks the original folder because it has yet to rename the remaining files from it. (But in reality they are now in the new folder)

So, Result#2: The old folder remains undeleted.

************

To confirm this hypothesis, I tried this simple experiment:

I placed a single file "Trial1" in a folder "Trial Folder".
Then I loaded both (folder first).
I used the Replace rule (replace "Trial" with "2").

Result:
1. The folder was renamed, but the original folder remained.
2. The file failed to be renamed.

Then I repeated the experiment with folder last. It worked without any problem.

QED!

********************
To conclude,
1. place the folders at the end (after their contents).
2. If you are using folders from a tree, place the folders in "leaf-to-root" order.

Last edited by narayan (2009-08-19 21:08)

narayan · 2009-08-19 21:07

In a supplementary experiment, I placed two files in the folder, and renamed only one file and the folder (with the folder listed last in the ReNamer).

Result:
Both the file and the folder got renamed (there is no folder by the old name).
The un-renamed file is now in the renamed folder.

That happened because the remaining file was not locked; and was free to "move" to the renamed folder.

Cantello · 2009-08-20 08:33

narayan wrote:

Then I repeated the experiment with folder last. It worked without any problem.
QED!
********************
To conclude,
1. place the folders at the end (after their contents).
2. If you are using folders from a tree, place the folders in "leaf-to-root" order.

Hey narayan,

I repeated your experiments and came to the exact same conclusion, great! :-)

Now I only have to be careful in which order to rename those pesky umlaut-ridden files.

Ta!

narayan · 2009-08-20 14:46

Glad you found that useful. Probably it would be simpler to rename the folders first and then rename the files in a second operation.

In case of nested folders, you would have to list inside-to-outside order.

If that's a repeated task, I'd suggest you use a couple of presets (http://www.den4b.com/wiki/ReNamer:Using_presets). First to load the folders only. Second time for the files only.

For both presets, set the filters, load the translit rule and then save.
(note that the filters need to be set differently to load files and folders; and the preset definition can save this filter condition).

krtek · 2009-08-20 17:51

Just in case.
The simplest way to achieve leaf-to-root or root-to-leaf order is to sort the files table by the Path (or Folder) column.
When the "triangle" is pointing up, you've got root-to-leaf order.
When the "triangle" is pointing down, you've got leaf-to-root order.

Last edited by krtek (2009-08-20 17:54)

den4b Forum

#1 2009-08-19 11:25

Renamed x files, failed to rename y files. Why?

#2 2009-08-19 11:52

Re: Renamed x files, failed to rename y files. Why?

#3 2009-08-19 11:57

Re: Renamed x files, failed to rename y files. Why?

#4 2009-08-19 16:15

Re: Renamed x files, failed to rename y files. Why?

#5 2009-08-19 18:14

Re: Renamed x files, failed to rename y files. Why?

#6 2009-08-19 20:47

Re: Renamed x files, failed to rename y files. Why?

#7 2009-08-19 21:07

Re: Renamed x files, failed to rename y files. Why?

#8 2009-08-20 08:33

Re: Renamed x files, failed to rename y files. Why?

#9 2009-08-20 14:46

Re: Renamed x files, failed to rename y files. Why?

#10 2009-08-20 17:51

Re: Renamed x files, failed to rename y files. Why?

Board footer