Diese Seite mit anderen teilen ...

Informationen zum Thema:
Forum:
WinDev Forum
Beiträge im Thema:
16
Erster Beitrag:
vor 11 Monaten, 2 Wochen
Letzter Beitrag:
vor 11 Monaten
Beteiligte Autoren:
Ola, Fabrice Harari, Al, GuenterP, iso, Bart VDE

[WD21] File structure modification problem

Startbeitrag von Ola am 10.11.2016 19:09

[WD21] File structure modification problem

Hello all!

I just run into a new strange problem in WD21 while testing my ERP's new upgrading system.

First stage in my development machine (WIN 7):

I fixed some bugs from my ERP and changed its file structure modification process to use the internal HModifyStructure command instead of the "good old" external WDModFic.Exe.
I also changed the file description of one of its files (a HFSQL classic file).

Next I made the upgrade package that updates the system, including the file modification using HModifyStructure, and uploaded it into my internet support site.

Then I went to my main production work station (WIN XP), which also serves as the file server for two other workstations (classic files, no C/S).

There I started the old version of the ERP and told it to check the internet support site for upgrades. A newer version was found, so I let the program upgrade itself. The download and upgrade process went smoothly, and the file structures were also upgraded automaticvally and smoothly (using HModifyStructure). The program then restarted in its new version and worked flawlessly. Everything OK so far.

Then I went to one of the other workstation and started the old version program there. It routinely checked if there is a newer system in the server macine, found that there was, and asked whether it can upgrade itself from the server. I answered yes. And so it did. No need for file structure modification, because that was already done when the server's program was updated.

Now, after the work station upgrade (a simple copying process), the new program did not re-start properly. It said that it cannot open the file whose structure was upgraded:
Error code: 70152
Level: fatal error
WD55 error code: 152

System error code: 5
System error message:
Käyttö estetty. (= Use denied or access denied in English)

Then, in my development machine, I tried to read the problem file (in the server) with WDMap. WDMap also refused to read it:
Description of file 'X:\ERP_Data\FILENAME.FIC' cannot be imported.
Unable to open file.
System Error Details: Käyttö estetty.

So I went back to the server machine, restarted the program there, and it opened OK, and the "problem file" also seemed to behave OK, and the added fields were there and functioned properly. Also checked other files in the server, and they opened without hic-ups.

Then I tried to copy the program file(s) from the server to the client machine. Only the .MMO file could be copied, the .FIC and .NDX files could not be copied: Access denied!

I tried re-indexing all the files in the server. No help.
I tried deleting the index file. No help.

I tried to check with Windows file Explorer whether there are some weird attributes in the problem file, but could not see any.

The modified file can be used in the same machine where it is, but not over LAN! All the other, the non-modified, files can be used from any work station. Does HModifyStructure somehow mess the files up?

I get the feeling that WD21 is just one show stopper after another. Definitely not 10 times faster.

So what is the problem? Thanks in advance for any hints on how to fix the file and solve the problem.

Best regards
Ola

Antworten:

Hi all,

This is a file right problem. I fixed the file just by setting its rights the same as all the others in the same directory. Now it's available to all work stations.

But, still, I wonder, why on earth did HModifyStructure change its rights????!!!
Luckily this happened to me and not any end user!

Has anybody else experienced this?

Best regards
Ola

von Ola - am 10.11.2016 21:04
Hello Ola

It happens all the time in Classic.
I think this is how it goes:
The HModify writes the existing file out to a temp file, creates a new structure using the rights of the logged in user rather than the original file rights and then copies the data back - instant problem.
Doesn't happen in HFCS because it manages its own rights.

Regards
Al

von Al - am 11.11.2016 08:38
Hi Ola,

to add to Al answer: this comes from the rights management in windows and depends of WHERE the file is situated. If your file is in the commanded (by windows) directory (ie user name/appdata...) because these files are set for this kind of work.

If it is somewhere else, then the new file inherits permission from a parent directory where you have no writing permission. This is true by example if you use a program file subdirectory.

Also, this is NOT a windev 21 (or any version problem), it comes directly from the tightening of security in windows/uac and was also happening with previous version... It seems that wdmodfic was doing some extra magic to avoid the problem, on top of modifying the file structure.

Best regards

von Fabrice Harari - am 11.11.2016 11:47
Hi Al and Fabrice

Thanks for the info.

I still wonder, is this really acceptable? That doing some operation an a file unexpectedly changes its rights?!?!?

Compare this to just copying or renaming a file, or editing a text file, or any file in any directory an any disk: what if the file rights were messed-up? Would it be acceptable?

I think not. And I do not see this kind of behavior by any other program that I am using. I think this is a very bad bug, and should be fixed ASAP.

Is there a way to programmatically fix the right of a file when PCSoft has messed it up?

Best regards
Ola

von Ola - am 15.11.2016 14:19
I had this problem, changed it from the mapped location to the full server path

eg: from

'X:\ERP_Data\FILENAME.FIC'

to

to '\\Server\ERP_Data\FILENAME.FIC'

von iso - am 15.11.2016 15:02
Hi again

@OLA: this is NOT a windev bug. It's the NORMAL behavior when using the WRONG directory for your file, and is due to the tightening of security rules by WINDOWS.

So change your code to work in places where windows want you to work, and everything will be fine.

von Fabrice Harari - am 15.11.2016 15:07
Hello Fabrice

I think I disagree with you about the wrong directory aspect. It is only a problem with Classic files and I had asked PCSoft tech support last year.
Their response was that it was documented behaviour of WDModfic
This is in the help file - not under WDModfic but in a section labelled Automatic modification of files.

Quote
PCSoft Help

Access rights to the data file
The modification of the data files triggers the re-creation of the data file on disk. In an allocation system managing the rights at file level (NTFS...), the data file after modification will have the rights of the directory to which it belongs.
Before the automatic modification, if the data file had specific rights different from the rights of the folder, they must be redefined in Windows after the modification.


Regards
Al

von Al - am 15.11.2016 20:20
Hello Al,

I'm saying that it is a known behavior coming from the windows rights management, and they are saying the same thing in the help you are copying here. So I'm not sure how you disagree with me by saying the same thing another way.


I quote:

>>the data file after modification will have the rights of the directory to which it belongs

So, if you use the WRONG directory (by example, but not limited to, \program files, C:\yourprogram, etc) in a modern windows, you have this problem. If you use the recommended directories (fdatadir or fdatadiruser), you don't have any problem, because the default rights for these directory are set the right way for this kind of process.
And of course in C/S, it's all managed by manta.

Best regards

von Fabrice Harari - am 16.11.2016 08:40
I find it rather poor in the first place that for logical modification (ALTER table), a physical file must be recreated.

von Bart VDE - am 16.11.2016 12:03
Hi Fabrice

"@OLA: this is NOT a windev bug. It's the NORMAL behavior when using the WRONG directory for your file, and is due to the tightening of security rules by WINDOWS."

Thank you for your explanation and instructions. I understand them except for one thing, which I don't quite get: Windows recommends the using of certain directories, but, it's only a recommendation, is it not?

Surely it can't be mandatory? If all programs and all data would have to be in certain directories on C:-disk only, then why do I have a D:-drive, an E:-drive, an F:-drive etc...? Why do they sell extra disks? Why does Windows allow the installation of extra disks?

What if I have a very small C:-drive (SSD for example), and it becomes full, as it easily may?

And there may also be other valid reasons than limited space to use other disks and directories than the recommended ones.

And, surely, it is not a Windows requirement that if any files are touched outside those recommended directories, then their usage rights must be messed-up? I wonder if it is even a standard. I tried to find some instructions about this, but could not find anything that says that if you touch a file outside the recommended directory, its rights should changed.

For comparison: If I edit, save and/or save as a text file in my server's data directory (specified by me and not Windows) with Microsoft Notepad, its rights are not changed. Why did Windows itself not mess around with the rights?

So far, I can see Windev's behavior in this case only as a very, very naughty bug.

Best regards
Ola

von Ola - am 18.11.2016 12:31
Quote
Ola
Thank you for your explanation and instructions. I understand them except for one thing, which I don't quite get: Windows recommends the using of certain directories, but, it's only a recommendation, is it not?


Hi Ola,

no, it's not only a recommendation because Microsoft enforces both \programs directories (32-bit & 64-bit) to be read-only. There are good reasons for that, namely security, a virus or some malware would have a hard time to infect the program files stored there.

Use \ProgramData instead, it's the recommended procedure is to store data in \ProgramData\YourCompanyName\YourAppName . \ProgramData replaces the former \All Users directory. Imho, the more idiotic M$-idea is to make \ProgramData invisible by standard - how should end users backup their data then? My solution on installing our programs is to make \ProgramData visible, that's all it needs.

Btw, I do not agree with the idea to have the HFSQL Server data stored in \Programs and I do not agree with having the data files of Reports & Queries there. If those data are for all users of the computer then they have to go to \ProgramData, if data is owned by a single user then data should go to \Users\UserName ..

There are even recommendations for moving those directories. Like https://support.microsoft.com/en-us/kb/949977 Ok, M$ doesn't keep to their own recommendations in many cases (there are several hundred programmers there and QC is seemingly not that good), Mr Klein points out the non-standard ideas here: https://helgeklein.com/blog/2012/08/windows-7-default-file-system-permissions-listing/

And there are tools out there to fix even the worst configuration problems on NTFS-level like SubInACL https://www.microsoft.com/en-us/download/details.aspx?id=23510 It's a very complex tool, some years back we could fix a Windows 2003 server using SubInACL, it's a phantastic tool and you definitely should know what you're doing.

von GuenterP - am 18.11.2016 15:08
Hi Ola,

once again, you are jumping to some conclusions on your own.
I said that some places should NOT be used (like program files or c:\xxxx) because I have read about those specifically.
I did NOT, however, said that ONLY programdata and userdata should be used. AFAIK, D and other extra hard drives are NOT subject to windows restrictions.

But if you want to know EXACTLY where you can and can not store your data, then you'll need to read out on it on msdn or other fully informed source.

Now, at this point, it seems clear to me that you have decided that it is a windev bug,, even after all the information we gave you... If that's the case, I cannot help you

Best regards

von Fabrice Harari - am 18.11.2016 17:04
Hi Fabrice & Guenter

Thank you both for additional information. I used to be a MSDN subscriber for some years in the 90's but found out it is not worth its price, especially considering that I have always been using high level programming languages, which I expect to take care of the miscellaneous system and program janitoring and bookkeeping bits and pieces, so that I can concentrate on practical app developing.

And that is what I expect also from Windev.

Is there a way to programmatically fix the rights of a file when PCSoft has messed it up?

Best regards
Ola

von Ola - am 19.11.2016 11:19
Quote
Ola
Is there a way to programmatically fix the rights of a file when PCSoft has messed it up?


Hi Ola, of course, find out how to use SubInACL and Exerun it, SubInACL is a command line tool. Imho it should even run in a 64-bit environment. Haven't tried it, but you can. Take an old PC or put an old hard disk into your PC and experiment a bit. Warning: it's not easy since this is a tool to fix NTFS hard disks and their most complicated problems.

von GuenterP - am 19.11.2016 11:49
Thanks Guenter,

That'll probably be one of the last straws...

I am now testing the ProgramData directory and the equivalent ...All Users\Application Data\Company name\Application name in XP.

These work only from the local machine. They can't be accessed from other machines.
What If I need to access the (classic) HFSQL data from other machines in the LAN?

What directory should I use, if I want to keep the data on the server's C disk and available to all machines in the LAN and safe from the rights-related calamity created by Windev's file structure change process??

Best regards
Ola

von Ola - am 20.11.2016 23:59
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.