Stuck in a rename loop

[ivan]

I've got a KS configured to execute this script:

Code: Select all

regexreplace $name, <curitem>, "^.+\\([^\\]+?)\\[^\\]+?.*$", "$1";
 rename bat, $name;

So i've got 2 files: abc.ext and xyz.ext (where ext is extension and is the same for both files). I click on abc.ext and hit my KS, it renames it into folder's name. I click on xyz.ext and hit my KS and it renames it into folder name with addition of "-01" as defined in config. I go to rename the latter to remove the "-01" off the end. I click off then then a Windows window pops up asking if I want to rename the latter into what it was but with (2) at the end. This is understandable because it has detected me trying to have 2 files with the same name and extension and god forbid a user trying to have that.

However, the way it's being dealt with is very inefficient. No, I don't to rename it into same but with (2) at the end. Yet, it won't have that. I can keep on clicking No until Logitech will go into liquidation but I'll still be stuck in that loop.

So 2 possibilities:

a) Allow me to click No and take me back to file in "edit name" mode so I can fix it myself

b) Allow 2 files with same name/ext in the same folder based on md5 to differentiate.

I know that having a) would be problematic because XYplorer uses a system function to throw the window. I also know that having b) would be more difficult because it's not native WE behaviour.

So what shall we do?

[jacky]

I go to rename the latter to remove the "-01" off the end. I click off then then a Windows window pops up asking if I want to rename the latter into what it was but with (2) at the end.

Could you explain what you do exactly here, because when I try to rename a file to an already existing name, I got a popup warning and then I'm back on Rename mode, I don't get either asked to go for a new number suffix nor do I enter a loop And your script doesn't ask for anything either, it uses automatic number suffix.
So, when/how do you get that exactly ?

I also know that having b) would be more difficult because it's not native WE behaviour.

Not more difficult, impossible. This has nothing to do with XY, but the file system. And I 'm pretty sure you can't have any filesystem that could allow such a thing, just think about it, you'd have no way at all of referencing one file and not the other, how could you possibly have two files with the exact same name !?

BTW, your script could be shorter using this I think:

Code: Select all

rename ,<curfolder>;

[ivan]

Could you explain what you do exactly here, because when I try to rename a file to an already existing name, I got a popup warning and then I'm back on Rename mode, I don't get either asked to go for a new number suffix nor do I enter a loop And your script doesn't ask for anything either, it uses automatic number suffix.
So, when/how do you get that exactly ?

Are you sure you're using the same OS as I do? I'm on Vista. XP does what you mention but Vista does not. I don't have a problem with the script. It was just a quick way to rename and then remove the suffix manually.

Not more difficult, impossible. This has nothing to do with XY, but the file system. And I 'm pretty sure you can't have any filesystem that could allow such a thing, just think about it, you'd have no way at all of referencing one file and not the other, how could you possibly have two files with the exact same name !?

Well a file is more than just a filename and extension. There are other unique (and less unique but still hard to match) characteristics about a file
like md5 hash, size etc

I think allowing 2 files with the same name is no more ridiculous than being able to have a file with no name at all, which XYplorer currently makes possible in Vista. Yet it's not possible in XP. It's not even possible in Vista in IE.

So I set up a little experiment on my Vista machine.

1. Made a dummy file with a file name and extension.
2. Removed file name so only extension is visible in XYplorer
3. Opened folder in WE and there it was with just the extension visible.

Things get even more ridiculous when I ticked "Hide extensions for known file types" in WE, which resulted just the icon showing. Excuse my French but that's a bit bloody stupid.

Back on topic for a touch. If XYplorer manages to overcome the native limitations of WE then surely we can hope that it'll go one step further in respect of differentiating between files with the same name/extension.

BTW, your script could be shorter using this I think:

Code: Select all

rename ,<curfolder>;

Yes, but yours doesn't take into account the extension of the file. So, if there's a file called ABC.avi then when trying to rename XYZ.txt into ABC.txt it will result in XYZ.txt being renamed into ABC-01.txt since it think that a file with the same name is already there

[jacky]

Are you sure you're using the same OS as I do? I'm on Vista. XP does what you mention but Vista does not. I don't have a problem with the script. It was just a quick way to rename and then remove the suffix manually.

Yes, I'm running XP indeed. But then if that's a Vista thing you're facing there, I don't think XY can do anything about it...

Well a file is more than just a filename and extension. There are other unique (and less unique but still hard to match) characteristics about a file
like md5 hash, size etc

Yeah, but that doesn't matter, it's not the same. Hash isn't a property or anything, as it must be calculated from the content, and size/dates are just properties, but all files (content, the actual data) are linked to using names, and you obviously can't have two exact names pointing to the same content, otherwise when using that name, there would be no way to tell which content should be accessed ! Filenames must be unique. And again, this isn't from XY, but your file system (FAT or more likely NTFS).

I think allowing 2 files with the same name is no more ridiculous than being able to have a file with no name at all, which XYplorer currently makes possible in Vista. Yet it's not possible in XP. It's not even possible in Vista in IE.

Yeah, but I don't think you can do that either. Filename is actually name and extension, the whole thing, and a file must have one, one that is unique (in that folder).
Of course, naming a file ".ext" and showing only names (hiding extension) might result in a file without a name, which is kinda stupid yeah, but that's Windows. And, in reality, there would be a filename, ".ext"

Anyways, once again this isn't anything XY can alter in any ways, it doesn't make the rule when it comes to the file system, just obey them.

Yes, but yours doesn't take into account the extension of the file. So, if there's a file called ABC.avi then when trying to rename XYZ.txt into ABC.txt it will result in XYZ.txt being renamed into ABC-01.txt since it think that a file with the same name is already there

hmm... are you sure? Cause both use Batch Rename, and so it works the same : extension are not included (unless /e is specified), so in both case it should be the same, since the regexreplace command should put inside $name the same thing that is in <curfolder> : the current folder's name.

I just tried here, and it works the same : both scripts rename XYZ.txt to ABC.txt when there's an ABC.avi present, they work the same for me, and I think this should be XY-only behavior, not OS-related...

[ivan]

Yes, I'm running XP indeed. But then if that's a Vista thing you're facing there, I don't think XY can do anything about it...

Au contraire mon freire. The fact that natively on Vista, whether in WE or just on the desktop, it's not possible to create just a file with extension and no file name proves that XY goes against the nativity, which in turn shows that XY is doing something about it.

Yeah, but that doesn't matter, it's not the same. Hash isn't a property or anything, as it must be calculated from the content, and size/dates are just properties, but all files (content, the actual data) are linked to using names, and you obviously can't have two exact names pointing to the same content, otherwise when using that name, there would be no way to tell which content should be accessed ! Filenames must be unique. And again, this isn't from XY, but your file system (FAT or more likely NTFS).

OK, I'll concede that there's no reasonable way to differentiate between 2 files with the same name. However, the way the Vista + XY combo goes about dealing with the situation when you're trying to have 2 files with same name and extension is less than satisfactory. Potentially, if you make a script that uses Windows API you can be stuck the an endless loop.

Yeah, but I don't think you can do that either. Filename is actually name and extension, the whole thing, and a file must have one, one that is unique (in that folder).
Of course, naming a file ".ext" and showing only names (hiding extension) might result in a file without a name, which is kinda stupid yeah, but that's Windows. And, in reality, there would be a filename, ".ext"

Anyways, once again this isn't anything XY can alter in any ways, it doesn't make the rule when it comes to the file system, just obey them.

Actually, a file name is a base name of a file, which includes everything up to the separator "." that divides a file name from extension. This is clearly proven if you try to create a new TXT file on your desktop (not in WE or XY) and then remove everything up to "." and see the error message that you get. So while Windows doesn't like you having files with no base name, XY manages to have its own way so how it obeys rules of the file system in that respect still escapes me.

Yes, you might want to have a ".htaccess" file which features no name as such but that wouldn't apply to vast majority.

hmm... are you sure? Cause both use Batch Rename, and so it works the same : extension are not included (unless /e is specified), so in both case it should be the same, since the regexreplace command should put inside $name the same thing that is in <curfolder> : the current folder's name.

I just tried here, and it works the same : both scripts rename XYZ.txt to ABC.txt when there's an ABC.avi present, they work the same for me, and I think this should be XY-only behavior, not OS-related...

Actually, just tried and both work. Not sure what was going on before but both scripts work as intended now. Doesn't matter which one I use though, right?

[jacky]

Au contraire mon freire. The fact that natively on Vista, whether in WE or just on the desktop, it's not possible to create just a file with extension and no file name proves that XY goes against the nativity, which in turn shows that XY is doing something about it.

Well, not really, because while Windows Explorer may not allow you to create a file whose filename starts with a dot, there's no limitations from the filesystem that prevents it, which is why XY can allow it : it is supported.

Actually, a file name is a base name of a file, which includes everything up to the separator "." that divides a file name from extension.

No, not really. That just comes from the old days where filenames where 8.3 and you had a name (1 to 8 chars, and no dots), and an extension (up to 3 chars) separated by a dot.
Those limitations are long gone now, but the old extension thing remains, it's a general convention to have a base name, and optionally a dot and an extension.

And in WE one can hide extension and ignore them, as if they didn't exists, letting Window take care of it. But in reality, they're here, and they're part of the filename.

Actually, just tried and both work. Not sure what was going on before but both scripts work as intended now. Doesn't matter which one I use though, right?

Nope, except that yours uses a call to regexp that can be avoided, so you're probably wasting one nanosecond each time you use it. Add them up, and at the end of the week that might be one millisecond of your time you'll never have again! Now, I'm not saying you can do a lot in one ms, but you know, one day you might find yourself wishing you had one more ms to spend on something, and that day you'll blame yourself for not just using the variable <curfolder> here...

Or not.

[ivan]

Well, not really, because while Windows Explorer may not allow you to create a file whose filename starts with a dot, there's no limitations from the filesystem that prevents it, which is why XY can allow it : it is supported.

But if I try to create a file on the desktop with no base name then am I doing it in WE? If not then where does the limitation come from?

What if I want to disable the creation of files with no base name in XY? Currently not possible to stop such so let's have that as another feature.

And in WE one can hide extension and ignore them, as if they didn't exists, letting Window take care of it. But in reality, they're here, and they're part of the filename.

Is is possible to do the same in XY? If so, then how? If not, then let's have it onboard too!

Nevertheless, going back to the way XY handles the situation when you try to rename into the same name on Vista, I think improvement can and should be made here. Clearly, the OS is hijacking the process and forces me to do what it wants me to do instead of what I want to do. Even going back to edit mode if I click No (like you can in XP) would be good. So is it possible not to use the system function on this one and have a custom XP-like behaviour?

[jacky]

But if I try to create a file on the desktop with no base name then am I doing it in WE? If not then where does the limitation come from?

Yes, it's pretty much the same as doing so in WE.

And I think it's a good thing XY doesn't allow to hide extension, since they're part of the filename and working on files without knowing their actual full name is always a risk.

[ivan]

Yes, it's pretty much the same as doing so in WE.

The same or pretty much the same? Is it going to be the good old "looks like a duck" and "quacks like a duck" exchange?

Clearly, the rules that are enforced in WE are also enforced on the desktop outside WE, but not in XY so how would it be possible to have XY rules on the desktop too?

And I think it's a good thing XY doesn't allow to hide extension, since they're part of the filename and working on files without knowing their actual full name is always a risk.

Equally, I believe it's extremely unconventional for a file not to have a base name. I also believe that creating a file without a base name in WE is prohibited for a reason. Hypothetically, what's stopping a rogue XYS file being created that gets imported and executed and removes base names from a bunch of files? That's a risk in my book. Would it be really that troubling to create an option to disable creating/renaming files into those with no base names?

[jacky]

The same or pretty much the same? Is it going to be the good old "looks like a duck" and "quacks like a duck" exchange?

Well, I wouldn't say it's the same because I don't think you can have Details view or such, but other than that it's about the same.

When one say Windows, it can refer to the OS or some (built-in) apps, like GUI elements. Desktop falls under the later, but a filename starting with a dot is supported, by Windows, by the file system.

Do not end a file or directory name with a trailing space or a period. Although the underlying file system may support such names, the operating system does not. However, it is acceptable to start a name with a period.

Hypothetically, what's stopping a rogue XYS file being created that gets imported and executed and removes base names from a bunch of files? That's a risk in my book.

Well, you could also load a script file that selects all and deletes everything, no confirm no bin, that's probably not good either I would assume. So, should XY allow to disable to ability to delete files altogether ? Certainly not.

Files can have their names starting with a dot, it's supported, there's no reason for XY to forbid it.

And I believe it is way more risky to see a file "readme.txt" while in reality it is called "readme.txt.exe" - an application. Then, you see a text file, dbl-click to open it and just started a virus or something like that. Hiding extension is bad, I strongly advice against it, and it's good XY doesn't an such an option IMO.

[eurytos]

You can create empty file names in windows it's only a restriction built into the gui. Errr, probably not even the gui, just the name/rename function that is called from the gui since windows explorer can see the file and allows you to open it.

you can test it by opening a command prompt.

If I had a file named test.txt in my current folder the following command will name it without a name before the dot:
rename test.txt .txt


or if you want to create a new file:
copy con .omg and then hit F-6 and enter
or:
edit .omg then file/save

using quotes you can do even more fun stuff:
copy con ". wut"
copy con " . wut"
copy con " ."



edit: looks like the forum ripped my spaces out
anyways the copy con statements with the quotes have a bunch of spaces before the file name or dot.

[ivan]

Well, you could also load a script file that selects all and deletes everything, no confirm no bin, that's probably not good either I would assume. So, should XY allow to disable to ability to delete files altogether ? Certainly not.

But XY does give you the option in Config->Advanced to always show delete confirmations. Does that mean that #170 overrides that? If so, then there should be another option in Config where person can choose whether scripts can override config settings.

Files can have their names starting with a dot, it's supported, there's no reason for XY to forbid it.

I am not asking for XY to forbid stuff like that outright, but I do see sense in having an option so a person cannot create a file with no base name. Even you said it's pretty stupid and I can only see sense when you have ".htaccess" file. There are no other uses.

And I believe it is way more risky to see a file "readme.txt" while in reality it is called "readme.txt.exe" - an application. Then, you see a text file, dbl-click to open it and just started a virus or something like that. Hiding extension is bad, I strongly advice against it, and it's good XY doesn't an such an option IMO.

Yes, there are risks in everything. However, I think such option was brought into WE for aesthetic benefit. Files with no visible extension on the end may look prettier. Once again, it's a personal choice. Someone moving on from WE onto XY may want that option and currently that isn't possible.

[TheQwerty]

Sometimes I'm in a rush and don't cross the street at the crosswalks. This can be very dangerous as drivers may not be paying attention and may not realize that I'm crossing. Could we get an option in XY to prevent me from crossing the street unless I'm in the designated areas?

Perhaps:
"WARNING WARNING WARNING!

You are about to cross the street at an area that is not designated for crossing.

Would you like to proceed?

-Yes
-No! Thank you XY for saving me!
-Only if you'll hold my hand."


Baseless filenames may seem odd in Windows, but in Linux and Unix they are very natural things. Some programs that have their roots from there continue to use such filenames, so XY users still need to manage them. There is no point in protecting the user from this.

I see absolutely no reason for an "Allow scripts to override delete confirmation setting" or "Hold me tightly XY and protect me from making baseless names" option. That's adding unnecessary complication and clutter.

Stepping and turning on/off scripting is more than enough to protect yourself from rogue scripts.


As for the ability to hide extensions... It's nice in WE for renaming the end of a number of files since you don't have to position yourself before the extension, but XY handles that already so it's a moot point. Otherwise, it may be nice to remove some redundant data in details view, but it's probably not worth Don spending the time on it, and slowing down the displaying of the list data.

[j_c_hallgren]

And in WE one can hide extension and ignore them, as if they didn't exists, letting Window take care of it. But in reality, they're here, and they're part of the filename.

Is is possible to do the same in XY? If so, then how? If not, then let's have it onboard too!

I recall that this has been seen as a wish before...at least once, but maybe more...mainly because the extension is avail via a separate visible selectable col that is not possible in WE, so one could chose not to hide them but simply have the names showing via two cols instead of just one, and which, for some cases/users. may be easier to read and/or work with.

So maybe IF the ability to hide extension from "name" col were linked to visibility of the "ext" col (and maybe "type" col?) thus always showing the complete name or equivalant, it might be more tolerable as an option?

Update: This was last discussed in http://www.xyplorer.com/xyfc/viewtopic.php?p=23235 where i posted a similar comment, but without above suggestion.

[ivan]

Baseless filenames may seem odd in Windows, but in Linux and Unix they are very natural things. Some programs that have their roots from there continue to use such filenames, so XY users still need to manage them. There is no point in protecting the user from this.

Considering that XYplorer works is designed for Windows-based systems, I don't see this "Linux and Unix" argument having a lot of weight. At the most, it's secondary to case and therefore less relevant.

I see absolutely no reason for an "Allow scripts to override delete confirmation setting" or "Hold me tightly XY and protect me from making baseless names" option. That's adding unnecessary complication and clutter.

Stepping and turning on/off scripting is more than enough to protect yourself from rogue scripts.

Well, it seems Don disagrees with you on that point. See link below:
http://www.xyplorer.com/xyfc/viewtopic. ... 1300#21300

Turning off scripting completely is way too radical if your only goal is to protect yourself from some of the riskier "side-effects" of it.

As for the ability to hide extensions... It's nice in WE for renaming the end of a number of files since you don't have to position yourself before the extension, but XY handles that already so it's a moot point. Otherwise, it may be nice to remove some redundant data in details view, but it's probably not worth Don spending the time on it, and slowing down the displaying of the list data.

Errr...XYplorer doesn't handle it at all. There is no option to hide extensions for known file types. I personally don't like when choices are made for me and if I want to sacrifice a little security for the purpose of aesthetics then I should be able to. Considering it's present in WE, I don't see an issue in porting it over.