Hi, I looked for the APIs wine had already implemented, but I didn't find, so I'll post this. I getting error with this API FindFirstFile. Wine does not show all of the attributes, not like Windows do. I made a program that reads from the command line the file you're looking for and displays all the attributes from the API. I've compared both runnings. Wine results are different from the Windows. Wasn't that API fully implemented? If so, why is the results differents? thanks, Ricardo.
--- Insyde <insyde(a)insyde.com.br> wrote:
Hi, I looked for the APIs wine had already implemented, but I didn't find, so I'll post this. I getting error with this API FindFirstFile. Wine does not show all of the attributes, not like Windows do. I made a program that reads from the command line the file you're looking for and displays all the attributes from the API. I've compared both runnings. Wine results are different from the Windows. Wasn't that API fully implemented? If so, why is the results differents?
Please, provide more details - what exactly are the differences? Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com
On Wednesday 08 May 2002 18:56, you wrote:
Hi, I looked for the APIs wine had already implemented, but I didn't find, so I'll post this. I getting error with this API FindFirstFile. Wine does not show all of the attributes, not like Windows do. I made a program that reads from the command line the file you're looking for and displays all the attributes from the API. I've compared both runnings. Wine results are different from the Windows. Wasn't that API fully implemented? If so, why is the results differents?
thanks, Ricardo.
Remember that Wine is a Unix application and must communicate with the operating system using Unix system calls - even if the underlying filesystem is FAT. Unix does not have the "Archive", "System", "Readonly" or "Hidden" flags so Wine cannot have them either. Actually, Wine sets the Readonly flag if the file permissions would prevent the current user from writing to the file, and the Archive bit is always set, but all other flags are clear. Dave
On May 8, 2002 03:42 pm, davep wrote:
Remember that Wine is a Unix application and must communicate with the operating system using Unix system calls - even if the underlying filesystem is FAT. Unix does not have the "Archive", "System", "Readonly" or "Hidden" flags so Wine cannot have them either.
Actually, Wine sets the Readonly flag if the file permissions would prevent the current user from writing to the file, and the Archive bit is always set, but all other flags are clear.
I would argue that we should set "Hidden" if and only if the filename starts with '.' What where the "Archive" and "System" bits used for? -- Dimi.
I would argue that we should set "Hidden" if and only if the filename starts with '.'
It's a good idea, but no file is called so in Windows. We could change the name of a file and add a '.' when windows asks to create a hidden file. Hope this won't create problems. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Dimitrie O. Paun wrote:
On May 8, 2002 03:42 pm, davep wrote:
Remember that Wine is a Unix application and must communicate with the operating system using Unix system calls - even if the underlying filesystem is FAT. Unix does not have the "Archive", "System", "Readonly" or "Hidden" flags so Wine cannot have them either.
Actually, Wine sets the Readonly flag if the file permissions would prevent the current user from writing to the file, and the Archive bit is always set, but all other flags are clear.
I would argue that we should set "Hidden" if and only if the filename starts with '.'
What where the "Archive" and "System" bits used for?
Archive was automatically set whenever the file would change. This way, backup programs could reset this flag when they backed up the system, and then perform an incremental backup of only the modified files (those with the A bit set). We may be able to simulate this behaviour by doing nasty tricks with the file change time vs. file modification time (clear the flag if the creation time is later than the modification time, and a request to clear the flag sets the creation time accordingly). Not sure I like this solution myself, however. System was used to denote a file that belongs to the system. It is not 100% clear to me what the relation between system and read-only is, but a read-write system file is a rare sight indeed. As for renaming hidden files to ".filename", that would break compatibility if Windows use the same directory. Shachar
In <3CDA0E30.1050300(a)sun.consumer.org.il>, on 05/09/02 at 08:50 AM, Shachar Shemesh <wine-devel(a)sun.consumer.org.il> said: :System was used to denote a file that belongs to the system. It is not :100% clear to me what the relation between system and read-only is, but :a read-write system file is a rare sight indeed. According to the IBM DOS 2.00 documentation, the two system files, IBMBIO.COM and IBMDOS.COM were marked as read only, hidden, and system files. 01 File is marked read-only. An attempt to open the file for output using function call hex 3D results in an error being returned. 02 Hidden file. The file is excluded from normal directory searches. 04 System file. The file is excluded from normal directory searches. 20 Archive bit. The bit is set on whenever the file has been written to and closed. -- Chuck Crayne ----------------------------------------------------------- ccrayne(a)crayne.org -----------------------------------------------------------
20 Archive bit. The bit is set on whenever the file has been written to and closed.
If described as above, every file should have this attribute (!) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Thu, May 09, 2002 at 10:00:21AM +0200, Sylvain Petreolle wrote:
20 Archive bit. The bit is set on whenever the file has been written to and closed.
If described as above, every file should have this attribute (!) Of course it should be like that. And we already do it like that; no news here, move on. I'd be pretty astonished if we failed to set it somewhere. (but then I've had shocking experiences with Wine API compatibility before, so...)
-- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/
Andreas Mohr a écrit :
On Thu, May 09, 2002 at 10:00:21AM +0200, Sylvain Petreolle wrote:
20 Archive bit. The bit is set on whenever the file has been written to and closed.
If described as above, every file should have this attribute (!) Of course it should be like that. And we already do it like that; no news here, move on. I'd be pretty astonished if we failed to set it somewhere. (but then I've had shocking experiences with Wine API compatibility before, so...)
Actually, the flag can be cleared (usually by a backup program, for incremental or differential backups). Now, I don't think (but could be wrong) that this flag is still used actively, even by backup programs (a database would probably be their best bet know, with a signature of the file). In Wine, the flag is only "set" when a program wants to know the attributes of a file; elsewhere, the attribute is non existent. So I guess it can stay that way. Insyde, does the Archive flag is one of the differences you saw? BTW, FAT32 or NTFS? Bye, Vincent
Actually, the flag can be cleared (usually by a backup program, for incremental or differential backups). Now, I don't think (but could be wrong) that this flag is still used actively, even by backup programs (a database would probably be their best bet know, with a signature of the file).
In Wine, the flag is only "set" when a program wants to know the attributes of a file; elsewhere, the attribute is non existent. So I guess it can stay that way.
Insyde, does the Archive flag is one of the differences you saw? BTW, FAT32 or NTFS?
Bye, Vincent
The "Archive" flag isn't used today : - no program cares about it in Windows (95+) - on NT it's only there for compatibility because ntfs has other inforamtion on a file such as owner, groups and so on. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Actually, the flag can be cleared (usually by a backup program, for incremental or differential backups). Now, I don't think (but could be wrong) that this flag is still used actively, even by backup programs (a database would probably be their best bet know, with a signature of the file).
In Wine, the flag is only "set" when a program wants to know the attributes of a file; elsewhere, the attribute is non existent. So I guess it can stay that way.
Insyde, does the Archive flag is one of the differences you saw? BTW, FAT32 or NTFS?
Bye, Vincent
Hi, Sorry for the late answer. My latest test, made this morning show some differences between W2K, W98 and Wine. The logs I have are: W2K: Target file is fff.c. The first file found is 1244784 The first alternate file found is 1245044 The first file attributes is 32 The first file found creation is -1416328896 The first file found last access is -1684948992 The first file found last write is -1827365376 The first file found (reserved0) is 16908546 The first file found (reserved1) is 16908546 The first file found size high is 0 The first file found size low is 1631 W98: Target file is fff.c. The first file found is 6552808 The first alternate file found is 6553068 The first file attributes is 32 The first file found creation is -1416328896 The first file found last access is -1684948992 The first file found last write is -1827365376 The first file found (reserved0) is 0 The first file found (reserved1) is 0 The first file found size high is 0 The first file found size low is 1631 Wine: Target file is fff.c. The first file found is 1079340360 The first alternate file found is 1079340620 The first file attributes is 32 The first file found creation is -1827365376 The first file found last access is -1684948992 The first file found last write is -1827365376 The first file found (reserved0) is 0 The first file found (reserved1) is 0 The first file found size high is 0 The first file found size low is 1631 The first file found, first alternate are always different. Attributes, last write, last access, size hig and low are always the same. Reserved 0 and 1 just make sense in W2K, so, no problem ins here. (Or there is when running --winver nt(35/40/2k)?) Wine is mismatching the Creation, both w2k and w98 have the same. (I test with the same file in a floppy, so always the same.) This is the source of the program I run to make the tests, I get this from MSDN and add some to it: -----8<--- begin of the source ------- #define _WIN32_WINNT 0x0400 #include "windows.h" int main(int argc, char *argv[]) { WIN32_FIND_DATA FindFileData; HANDLE hFind; printf ("Target file is %s.\n", argv[1]); hFind = FindFirstFile(argv[1], &FindFileData); if (hFind == INVALID_HANDLE_VALUE) { printf ("Invalid File Handle. Get Last Error reports %d\n", GetLastError ()); } else { printf ("The first file found is %d\n", FindFileData.cFileName); printf ("The first alternate file found is %d\n", FindFileData.cAlternateFileName); printf ("The first file attributes is %d\n", FindFileData.dwFileAttributes); printf ("The first file found creation is %d\n", FindFileData.ftCreationTime); printf ("The first file found last access is %d\n", FindFileData.ftLastAccessTime); printf ("The first file found last write is %d\n", FindFileData.ftLastWriteTime); printf ("The first file found (reserved0) is %d\n", FindFileData.dwReserved0); printf ("The first file found (reserved1) is %d\n", FindFileData.dwReserved1); printf ("The first file found size high is %d\n", FindFileData.nFileSizeHigh); printf ("The first file found size low is %d\n", FindFileData.nFileSizeLow); FindClose(hFind); } return (0); } /* typedef struct _WIN32_FIND_DATA { DWORD dwFileAttributes; FILETIME ftCreationTime; FILETIME ftLastAccessTime; FILETIME ftLastWriteTime; DWORD nFileSizeHigh; DWORD nFileSizeLow; DWORD dwReserved0; DWORD dwReserved1; TCHAR cFileName[ MAX_PATH ]; TCHAR cAlternateFileName[ 14 ]; } WIN32_FIND_DATA, *PWIN32_FIND_DATA; */ ----- 8< end of the source ------ Hope this help you. Thanks, Ricardo.
Insyde a écrit :
Actually, the flag can be cleared (usually by a backup program, for incremental or differential backups). Now, I don't think (but could be wrong) that this flag is still used actively, even by backup programs (a database would probably be their best bet know, with a signature of the file).
In Wine, the flag is only "set" when a program wants to know the attributes of a file; elsewhere, the attribute is non existent. So I guess it can stay that way.
Insyde, does the Archive flag is one of the differences you saw? BTW, FAT32 or NTFS?
Bye, Vincent
Hi,
Hi,
Sorry for the late answer. My latest test, made this morning show some differences between W2K, W98 and Wine. The logs I have are:
[snip]
Wine:
Target file is fff.c. The first file found is 1079340360 The first alternate file found is 1079340620 The first file attributes is 32 The first file found creation is -1827365376 The first file found last access is -1684948992 The first file found last write is -1827365376 The first file found (reserved0) is 0 The first file found (reserved1) is 0 The first file found size high is 0 The first file found size low is 1631
So the creation and last write are the same... The problem lies in FILE_FillInfo (files/file.c). In fact, the problem lies in that Unix doesn't keep the creation time; instead, it keeps (along with "last modification" and "last access") a "last change" time (st_ctime), which reflects the last change to the inode of a file. Such a change can include athe creation of the file, but also change to the owner, permissions, etc., so it's not quite the same thing as the creation time Windows expects. It _could_ be used, but then somebody would have to check if the VFAT layer of Linux reads that time correctly on a VFAT. And it won't necessarily give the same info as under Windows. The included patch uses st_ctime for CreationTime, but I'm not sure it's good. The right answer is "not easily doable".
The first file found, first alternate are always different. Attributes, last write, last access, size hig and low are always the same. Reserved 0 and 1 just make sense in W2K, so, no problem ins here. (Or there is when running --winver nt(35/40/2k)?) Wine is mismatching the Creation, both w2k and w98 have the same. (I test with the same file in a floppy, so always the same.)
Sidenote: I thought floppies were FAT12, and I don't recall more than one time stored in a FAT12 (or FAT16). But that was before Win95, so it might have been extended to include such things, the same way long names are held in more than a directory slot.
This is the source of the program I run to make the tests, I get this from MSDN and add some to it:
[snip]
Hope this help you. Thanks, Ricardo.
Vincent --- files/file.c.orig Thu May 9 10:55:51 2002 +++ files/file.c Sun Apr 28 20:01:55 2002 @@ -659,7 +659,7 @@ if (!(st->st_mode & S_IWUSR)) info->dwFileAttributes |= FILE_ATTRIBUTE_READONLY; - RtlSecondsSince1970ToTime( st->st_mtime, &info->ftCreationTime ); + RtlSecondsSince1970ToTime( st->st_ctime, &info->ftCreationTime ); RtlSecondsSince1970ToTime( st->st_mtime, &info->ftLastWriteTime ); RtlSecondsSince1970ToTime( st->st_atime, &info->ftLastAccessTime );
So the creation and last write are the same...
The problem lies in FILE_FillInfo (files/file.c). In fact, the problem lies in that Unix doesn't keep the creation time; instead, it keeps (along with "last modification" and "last access") a "last change" time (st_ctime), which reflects the last change to the inode of a file.
Someone will probably correct me here! but I'm sure the 'ctime' field was originally effectively a file create time. Unfortunately POSIX (and now the SuS) have converted it into a 'inode modified time'. IIRC updating the 'last accessed' time is deemed a modification of the inode. Certainly a change in the file size is such a modification. This renders the ctime field virtually useless. Indeed both the ctime and atime fields are a performance nightmare!
Sidenote: I thought floppies were FAT12, and I don't recall more than one time stored in a FAT12 (or FAT16).
I think that file systems that would have less that 2^12 extents are created FAT12. This is typically all floppies (4Mb with 2 sector extents). Everything else is FAT16 - with larger extents if the number of FAT entries would exceed 2^15. However there are large disks that appear to be floppies. eg LS120 (usually has a partiton table), and some devices only sold in Japan... David -- David Laight: david(a)l8s.co.uk
On May 9, 2002 01:50 am, Shachar Shemesh wrote:
As for renaming hidden files to ".filename", that would break compatibility if Windows use the same directory.
True. That was a bit strong. What about if filename starts with '.', return Hidden = 1, else return Hidden = 0, and we ignore all requests to modify the Hidden flag. -- Dimi.
In <200205101508.36213.dimi(a)bigfoot.com>, on 05/10/02 at 03:08 PM, "Dimitrie O. Paun" <dimi(a)bigfoot.com> said: :True. That was a bit strong. What about if filename starts with '.', :return Hidden = 1, else return Hidden = 0, and we ignore all requests to :modify the Hidden flag. What about if the physical file system is FAT, we support all of the flags just like Windows does. -- Chuck Crayne ----------------------------------------------------------- ccrayne(a)crayne.org -----------------------------------------------------------
On May 10, 2002 04:35 pm, ccrayne(a)crayne.org wrote:
In <200205101508.36213.dimi(a)bigfoot.com>, on 05/10/02
at 03:08 PM, "Dimitrie O. Paun" <dimi(a)bigfoot.com> said: :True. That was a bit strong. What about if filename starts with '.', :return Hidden = 1, else return Hidden = 0, and we ignore all requests to :modify the Hidden flag.
What about if the physical file system is FAT, we support all of the flags just like Windows does.
I guess we need a kernel with Extended Atributes (EA). It's in Linux 2.5, but until 2.6 is distributed to the general public, we're still a long way off... -- Dimi.
In <200205111350.25529.dimi(a)bigfoot.com>, on 05/11/02 at 01:50 PM, "Dimitrie O. Paun" <dimi(a)bigfoot.com> said: :> What about if the physical file system is FAT, we support all of the flags :> just like Windows does. :I guess we need a kernel with Extended Atributes (EA). :It's in Linux 2.5, but until 2.6 is distributed to the general public, :we're still a long way off... I agree that when Wine is emulating FAT on some other file system, waiting for a kernel with EA support is a reasonably strategy. However, I do not yet understand why this kernel support is required when the physical file system is FAT. Does not the VFAT ioctl read and write the actual directory entries in such a case? -- Chuck Crayne ----------------------------------------------------------- ccrayne(a)crayne.org -----------------------------------------------------------
participants (11)
-
Andreas Mohr -
Andriy Palamarchuk -
ccrayne＠crayne.org -
davep -
David Laight -
Dimitrie O. Paun -
Dimitrie O. Paun -
Insyde -
Shachar Shemesh -
Sylvain Petreolle -
Vincent Béron