You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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.)
The text was updated successfully, but these errors were encountered: