0

I'm using BoUML 7.10, the latest version, on Windows 10 Professional at work. By default, it installs to C:\Program Files (x86)\BoUML (or something very similar).

When a new project is created, it creates a subdirectory in that directory. Somehow, it creates the directory in a way that Windows CAN'T SEE IT. Trying to change the standard H(idden) and S(ystem) attribute flags on the listing of the containing directory doesn't work. NONE of the Windows command line tools see the subdirectory, or the files in it, making it impossible to delete the files if necessary - and I managed to make a mess that created a "lock" file, that must be manually deleted.

The GNU "find" utility, ported to Windows, does see the invisible subdirectory and all the files. The -name and -name0 options to find work. The -ld option doesn't; apparently, there is something different in the way directory entries are structured. I haven't tried the -delete option yet.

I ran a full chkdsk. It reported that nothing was wrong. I tried uninstalling and reinstalling BoUML, deleting the directory in between steps. After reinstalling it, the invisible project directory was still there, and so was the lock file.

Have any of you ever run into anything like this? Any ideas? Any suggestions on how to proceed, that DON'T involve nuking the computer from orbit? There USED to be specialized DOS utilities for working on corrupted directories, but that was a long time ago and I don't know whether anything like exists for Windows.

UPDATE:

I did some more experimenting early this morning. (Insomnia is a terrible thing.) First, I confirmed that it is Windows 10 Professional. (It is a somewhat-old build of Windows 10: our IT guys are conservative about loading updates.)

GNU find sees the cloaked directory ONLY if it is running from inside a GNU Emacs shell, which apparently uses a seven-year-old version of cmdproxy.exe to feed commands to Windows. It doesn't see it from a straight-up cmd.exe desktop shell, or from Windows Power Shell, whether run as Administrator or as a normal user. BoUML sees it when run as a normal user.

I have a ticket open with our IT guys. It will be interesting to see what happens. Absolute worst case is I go buy a USB hard drive, we take a mega-backup, and then we nuke the whole PC from orbit and rebuild.

UPDATE AGAIN

I just saw this question.

Windows permission differences between spawning from Explorer and from cmd.exe

This MIGHT have something to do with it, or MIGHT offer a clue. I just don't know.

John R. Strohm
  • 151
  • 1
  • 5
  • Since this is a proprietary product, you might get help from their tech support... or contact *marketing*, if support is not helpful, to let them know sales are in jeopardy. – DrMoishe Pippik Jan 10 '21 at 21:37
  • @DrMoishePippik: Already did that. It is a one-man project, free (as in beer). The guy says he didn't change anything. It MAY have something to do with our IT people doing something weird in the way they lock down the company PCs. – John R. Strohm Jan 10 '21 at 21:38
  • @BenN: THANK YOU!!! THAT WAS IT!!! EXACTLY!!! – John R. Strohm Jan 11 '21 at 02:41
  • (for other people) *When a new project is created, it creates a subdirectory in that directory* : my tool creates the subdirectory where the user ask me to do, there is a *default directory* but it is not a *mandatory directory* – bruno Jan 11 '21 at 10:05
  • @bruno: There's a special case in Windows. If you try to create a directory in certain places, Windows MAY under some circumstances **SILENTLY** create the directory SOMEWHERE ELSE, as described in the now-linked question, and **SILENTLY** redirect SOME BUT NOT ALL requests to the SOMEWHERE ELSE. The key phrase is "UAC Virtualization". (I think UAC is "User Access Control".) This results in the "invisible directory" behavior I saw: Our IT people have our PCs set up so that creating the project in the install directory tickles the special case. – John R. Strohm Jan 11 '21 at 14:12
  • @JohnR.Strohm yes, anyway even Windows allows to create the directory under the install directory of BoUML, this is a bad idea, a BoUML project is not a program and does not have to be placed among them. – bruno Jan 11 '21 at 14:20

0 Answers0