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

Warning message when renaming or copying files? #1903

Open
rmkaplan opened this issue Dec 11, 2024 · 0 comments
Open

Warning message when renaming or copying files? #1903

rmkaplan opened this issue Dec 11, 2024 · 0 comments

Comments

@rmkaplan
Copy link
Contributor

This is related to discussions in #1900 and #1830 .

There is a warning message in the UFS renaming function that tells the user that the type of the file is changing from TEXT to BINARY. The intent of this, presumably, is to simulate the are-you-sure interaction in, say, the Mac finder when the user renames a file by changing the extension. The intention is good, but the implementation here is bogus.

First, the current warning is at the wrong level. It is inside the device-specific \UFSRenameFile function, so it only shows up when you are renaming a Unix or DSK file to something else. And then it only applies when the new file name is not on the Unix or DSK file device. But why is that Unix/Dsk specific: if you were renaming from or to an IFS or NFS server, wouldn't the type-changing still be an issue? If this is a worthwhile warning, then it should be generic and apply no matter what the source and destination are. Even if you are renaming from Unix/DSK to Unix/DSK?

Second, the conditioning doesn't seem to capture the intent, at least in a modern context. Basically, we only know about 2 types, TEXT and BINARY, and maybe that's the only distinction that mattered for the different Xerox file servers. In the current implementation, there is a mapping between the extension in the file's name and either TEXT or BINARY, as defined by the variables DEFAULTFILETYPE and DEFAULTFILETYPELIST.

Warning the user that he is changing from a TEXT extension to a BINARY extension might be better than nothing, but that distinction is really too coarse, especially if the point is to prevent mistakes that will screw up later actions on the file. To take an example, TEXT and TXT are the canonical extensions for text files, and that extension is typically what controls the application that the operating system brings up to open the file (Textedit, BBedit...). But Tex files also contain only textual characters, but the opening of a .tex file brings it up in Texshop (at least on a Mac), which has also sorts of different behaviors. Similarly, .z, gz, gzip, tar... are all binary files, but they open in different ways.

So if we are really trying to warn the user that he is about to screw something up, the safest and most precise condition would be simply that the extension of the new file is not the same as the extension of the old file. Better still would be to keep a list of type-equivalent extensions, so that there would be no warning if switching between TXT and TEXT, or TED and TEDIT, but switching TEXT to TEDIT or TAR to GZIP would produce the warning (even though both binary).

Finally, I suggested above that at least this should be a device-independent warning. But perhaps it also should not even be done within the RENAMEFILE function. If you were in a programmatic loop systematically changing TXT to TEXT, you wouldn't want to see this warning for every file. On the other hand, if the rename is happening at a user-interface level, for example, the "rename" menu item in the file browser, then it would make more sense to put up a warning (maybe with a confirmation requirement) to guard against typos. (In which case the warning should be a MOUSECONFIRM and not just print an after-the-fact message in the promptwindow.)

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

1 participant