OS-depending differences in file-structure and file-access

Ask your support questions in here

Moderator: Moderator Team

Post Reply
Posts: 36
Joined: Tue Feb 01, 2005 12:13 am
Location: Koenigswinter, near to Bonn, Germany

OS-depending differences in file-structure and file-access

Post by videlux »

Inconsistency in the file-structure and file-access depending on which OS or application I use:

On the basis of my real-hardware-installation(s) I have repeatedly this problem: Files and directories, that have been written by ReactOS are not visible, or well visible but impossible to view, edit or delete.

My manner and tools to access the files are:
1. By ReactOS itself: a) The ROS-Explorer, the terminal with command-line, mc (midnight commander) started within a terminal or by the run-item in the start-menu.
2. FreeDOS: a) The command-line, b) volkov-commander, c) Treeview
(TreeView is a rather old, but my favotite, widely configurable, fine file-manager which I always used since my beginnings with (DR-) DOS in 1986 approx. The only current problem with TreeView is, that it is not supported any more and cannot handle the full long file-names. Therefore I am glad, having found volkov-commander as the dos-variant of midnight commander. VC is able to handle long file names)
3. Linux: a) mc b) the command-line, c) Konqueror

Even if in DOS none of the four tags "hidden, system, read-only, archive" are set, it happens, that some files are displayed, but are not accessible to change or to delete by ReactOS command line or explorer nor by FreeDOS. Only by accessing those files with Linux, I was able to change or delete them.

The first file, I tried to change this way is the freeldr.ini

So It could happen, that freeldr.ini is displayed by the dir-command. But when trying to rename it to frldrori.ini for example, I get the message "unable to rename freeldr.ini file does not exist" the same is true by trying to delete the file.
Accessing the files with Linux (as root) I can read, copy and delete the file as meant.
(This does not need to be a special problem related to ReactOS. I remember a collegue dealing with files on a redmond´s NT-System. Also there he saw a whole directory with files by the dir-command, but when trying to delete the files, the system responded that those files did not exist. Maybe he did, what people often do when worried by that OS: New installation.)

Having installed an application within ReactOS which created new directories, and afterwards accessing the file-system by FreeDOS I made another funny experience: FreeDOS´ dir-command itself and TreeView showed the new directories and files.
Viewing the file-structure with volkov-commander, a complete directory was not visible. As far as I remember (AFAIR) it was the whole directory "programs" or "Programme" in german respectively.

This became obvious with my efforts to install Capella 2000 (look into another thread of mine, concerning the question how to completely "undo" an installation):
The Capella installation-procedure seemed to run successfully and stopped with some message like "installation complete" . There was displayed the copying of something about 8 directories and subdirectories and about 10 up to 200 files, depending on the quantity of examples and tutorials one chooses during installation. When choosing the minimum installation, only about 10 program-files plus some templates need to be copied.

But during that "successful installation" I wondered that the procedure reached the end of installation within 2 seconds, but I could not recognize any remarkable hard-drive-activity.
And indeed, when looking into the file-structure, no files have been copied, only two lines are added in the registry.
Now I tried to start the application by ReactOS immediately on the installation-CD and I was surprised, that this was possible.
Thus I decided, to manually copy the whole file-structure (identical to the one, the Capella-installation-output claimed to have done) from CD to ReactOS´ harddisk-file-structure.
Finally I succeeded in making Capella run from harddisk.

But nevertheless on my way to there, I had some difficulties:
As mentioned, the effort to install Capella with it´s own installation procedure failed, because no directories had been made, nor files had been copied.
The default-Capella-directory should be "capella 2000".
Wondering, if the space in the directories name made some trouble, I had repeated the installation by choosing another directoryname during the installation procedure - same disappointment!

When trying to manually make the directory \programs\capella 2000 I got a message like "file already exists" although nothing was visible by the dir-command.

Finally it´s only by Linux that I succeed to handle the files.
And concerning the capella-installation (and maybe similar to other failed software-installations reported in ReactOS´ forum running applications) my conclusion is, that the installation-procedure does not really copy or write all the necessary files it should do, but ignores the fact, that the files havn´t been written.

The resulting question is: Where do I need to search for some FAT-related file-information or tag or whatsoever, to find the reason for the described access-problems?

I know, maybe it would be better to have some debugging-information, but unfortunately I did not yet succeed in realizing a running serial terminal to trace any output.


Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests