Re: New eject command issue
Brian Vincent wrote:
On 11/7/05, Christian Costa [EMAIL PROTECTED] wrote:
The error (21) suggest the drive is not ready or is finishing something.
Could you add a delay before the ejection IOCTL ?
No difference with this:
if (!DeviceIoControl( handle, IOCTL_STORAGE_MEDIA_REMOVAL,
removal, sizeof(removal), NULL, 0, result, NULL ))
WINE_WARN( IOCTL_STORAGE_MEDIA_REMOVAL failed with err
%ld\n, GetLastError() );
+sleep(60);
+
if (!unmount_only)
{
if (!DeviceIoControl( handle, IOCTL_STORAGE_EJECT_MEDIA,
NULL, 0, NULL, 0, result, NULL ))
It still umounts and then exits. Running it a second time works.
It's a laptop, not sure if that matters.
-Brian
60s ! Stange !
And during this delay are you able to eject by pushing the drive button ?
Are there files opened during this delay ?
Another thing, you may try duplicating the code and adding delays to
reproduce the 2 invocations of eject and
then narrow down things to determine which ioctl should be called twice.
Bye,
Christian
Re: New eject command issue
Brian Vincent [EMAIL PROTECTED] writes: Maybe I'm just unclear on the usage. It appears the first time it unmounts the drive and then the second time it actually ejects it. Is that intended behavior? No, it should be able to eject the first time. -- Alexandre Julliard [EMAIL PROTECTED]
Re: New eject command issue
Brian Vincent wrote: On 11/5/05, Brian Vincent [EMAIL PROTECTED] wrote: Then wine eject doesn't work the first time I try it. The second time I run it, it works fine. Maybe I'm just unclear on the usage. It appears the first time it unmounts the drive and then the second time it actually ejects it. Is that intended behavior? -Brian The error (21) suggest the drive is not ready or is finishing something. Could you add a delay before the ejection IOCTL ?
Re: New eject command issue
On Mon, 07 Nov 2005 23:39:20 +0100, Christian Costa [EMAIL PROTECTED] wrote: Brian Vincent wrote: On 11/5/05, Brian Vincent [EMAIL PROTECTED] wrote: Then wine eject doesn't work the first time I try it. The second time I run it, it works fine. Maybe I'm just unclear on the usage. It appears the first time it unmounts the drive and then the second time it actually ejects it. Is that intended behavior? -Brian The error (21) suggest the drive is not ready or is finishing something. Could you add a delay before the ejection IOCTL ? umount is not instantaneous, it may involve large buffer flushing and fs updates, is mount returning before all this is done?
Re: New eject command issue
On 11/1/05, Christian Costa [EMAIL PROTECTED] wrote: I tried to use the new eject command and this does not seem to work. Odd thing here as well. Fedora Core 4. This is wine CVS as of a few days ago, I don't think anything has changed in this area. If dosdevices contains a normal: lrwxrwxrwx 1 vinn vinn 18 Nov 5 15:37 d: - /media/cdrecorder/ Then wine eject doesn't work the first time I try it. The second time I run it, it works fine. Debugging output shows this the first time I try it: [EMAIL PROTECTED] dosdevices]$ WINEDEBUG=+eject wine eject trace:eject:eject_cd ejecting d: warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170 warn:eject:eject_cd IOCTL_STORAGE_EJECT_MEDIA failed with err 21 Then the second time: [EMAIL PROTECTED] dosdevices]$ WINEDEBUG=+eject wine eject trace:eject:eject_cd ejecting d: warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170 -Brian
Re: New eject command issue
On 11/5/05, Brian Vincent [EMAIL PROTECTED] wrote: Then wine eject doesn't work the first time I try it. The second time I run it, it works fine. Maybe I'm just unclear on the usage. It appears the first time it unmounts the drive and then the second time it actually ejects it. Is that intended behavior? -Brian
Re: New eject command issue
FSCTL_DISMOUNT_VOLUME : in DIR_unmount_device (in ntdll/directory.c): - unmount_device server call (in fd.c) is called but in unmount_device, the function tries to retreive a device object given the device return by fstat but no device object has been previously created so get_device fails. My understanding is that this server call should closed all fds associated with the device but files stay opened. It closes them in the server, but it can't close them in the client. They are open in the client because your CD has not been detected as a removable device so the client doesn't know that it shouldn't cache fds. I will hack FILE_GetDeviceInfo just to make it recognize my cdrom as removable and try to see if it helps. However, I don't understand well why forcing the drive as cdrom (instead of relying on autodetection) is not taken into account. This could be also usefull for ISO images. Unless this option is planned to be removed !?! Thx, Christian
Re: New eject command issue
Christian Costa [EMAIL PROTECTED] writes: I will hack FILE_GetDeviceInfo just to make it recognize my cdrom as removable and try to see if it helps. However, I don't understand well why forcing the drive as cdrom (instead of relying on autodetection) is not taken into account. This could be also usefull for ISO images. Unless this option is planned to be removed !?! We can't do that because all we have is a file handle, and there's no way to know which drive it was opened from. Besides, you don't really want that anyway, whether you open d:\foo or z:\mnt\cdrom\foo doesn't change the fact that foo is on a removable device. So we really need to make autodetection work properly (it does work fine for ISO images BTW). -- Alexandre Julliard [EMAIL PROTECTED]
Re: New eject command issue
Alexandre Julliard wrote: Christian Costa [EMAIL PROTECTED] writes: I will hack FILE_GetDeviceInfo just to make it recognize my cdrom as removable and try to see if it helps. However, I don't understand well why forcing the drive as cdrom (instead of relying on autodetection) is not taken into account. This could be also usefull for ISO images. Unless this option is planned to be removed !?! We can't do that because all we have is a file handle, and there's no way to know which drive it was opened from. Besides, you don't really want that anyway, whether you open d:\foo or z:\mnt\cdrom\foo doesn't change the fact that foo is on a removable device. So we really need to make autodetection work properly (it does work fine for ISO images BTW). Ok thanks, it is clearer in my mind. I made FILE_GetDeviceInfo recognize my cdroms and it works. I just need now to figure out why the fs magic id is wrong. Thanks a lot for your time and explanations. Bye, Christian
Re: New eject command issue
Alexandre Julliard wrote: Christian Costa [EMAIL PROTECTED] writes: If I set H: to autodetect, GetDriveType returns DRIVE_FIXED (3). Then you need to figure out why FILE_GetDeviceInfo doesn't recognize it as a CDROM. Something wrong is happening here, fstatfs return a good fs magic ID for reiserfs and vfat partitions. However, for the cdrom it returns 0x9fa1 which corresponds to OPENPROM fs !?! (and this for my cdreader and my cd recorder) I don't know why I get this but this make autodetection unusable for CDROM. I've done some further investigations and I found some strange things for the IOCTL involved in eject. FSCTL_DISMOUNT_VOLUME : in DIR_unmount_device (in ntdll/directory.c): - unmount_device server call (in fd.c) is called but in unmount_device, the function tries to retreive a device object given the device return by fstat but no device object has been previously created so get_device fails. My understanding is that this server call should closed all fds associated with the device but files stay opened. - system(umount ) is called to unmount the device but umount requires to be root and the return code of umount command is not tested so the call fails silently and FSCTL_DISMOUNT_VOLUME returns a success status IOCTL_STORAGE_MEDIA_REMOVAL : in CDROM_ControlEjection (ntdll/cdrom.c), it seems the CDROM_LOCKDOOR ioctl is not supported on my box for both the cdreader and the cdrecorder. IOCTL_STORAGE_EJECT_MEDIA in CDROM_SetTray (ntdll/cdrom.c), the CDROMEJECT works for my cdrecorder but I think it should not because the cd is still mounted and I can see the cached data even if I change the CD by another one. Well, I don't know if there is usefull information here but it's what I've found so far... Thx, Christian
Re: New eject command issue
Christian Costa [EMAIL PROTECTED] writes: Something wrong is happening here, fstatfs return a good fs magic ID for reiserfs and vfat partitions. However, for the cdrom it returns 0x9fa1 which corresponds to OPENPROM fs !?! (and this for my cdreader and my cd recorder) Something is wrong here... FSCTL_DISMOUNT_VOLUME : in DIR_unmount_device (in ntdll/directory.c): - unmount_device server call (in fd.c) is called but in unmount_device, the function tries to retreive a device object given the device return by fstat but no device object has been previously created so get_device fails. My understanding is that this server call should closed all fds associated with the device but files stay opened. It closes them in the server, but it can't close them in the client. They are open in the client because your CD has not been detected as a removable device so the client doesn't know that it shouldn't cache fds. - system(umount ) is called to unmount the device but umount requires to be root and the return code of umount command is not tested so the call fails silently and FSCTL_DISMOUNT_VOLUME returns a success status Yes, the device has been unmounted as far as the server is concerned, any subsequent access to the files will fail, so it makes sense to return success. The Unix unmount is really a best effort kind of thing, it can fail for a lot of reasons, like other apps having open files, but we don't want to return a failure in that case. -- Alexandre Julliard [EMAIL PROTECTED]
New eject command issue
Hi, I tried to use the new eject command and this does not seem to work. For that, I run a exe on the cdrom and try to eject the cdrom with : WINEDEBUG=+eject wine eject and I get : trace:eject:eject_cd ejecting h: warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170 warn:eject:eject_cd IOCTL_STORAGE_EJECT_MEDIA failed with err 170 and nothing happen and files are still open on the cdrom as shown below : bash 1243 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14747 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14747 titan memREG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14747 titan6r DIR0,8 0219136 /mnt/cdrom wineserve 14751 titan 22r DIR0,8 0219136 /mnt/cdrom wineserve 14751 titan 23r REG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14752 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14752 titan memREG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14752 titan6r DIR0,8 0219136 /mnt/cdrom wine-prel 14753 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14753 titan memREG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14753 titan6r DIR0,8 0219136 /mnt/cdrom Is there anything particular to do ? Morover, it seems eject is not installed so I have to run from the programs directory. I have also found that there is already a eject command in my distro (Mandrake). So this conflict may require renaming the eject command. Any idea ? Bye, Christian
Re: New eject command issue
Christian Costa [EMAIL PROTECTED] writes: and I get : trace:eject:eject_cd ejecting h: warn:eject:eject_cd IOCTL_STORAGE_MEDIA_REMOVAL failed with err 170 warn:eject:eject_cd IOCTL_STORAGE_EJECT_MEDIA failed with err 170 and nothing happen and files are still open on the cdrom as shown below : bash 1243 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14747 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14747 titan memREG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14747 titan6r DIR0,8 0219136 /mnt/cdrom wineserve 14751 titan 22r DIR0,8 0219136 /mnt/cdrom wineserve 14751 titan 23r REG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14752 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14752 titan memREG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14752 titan6r DIR0,8 0219136 /mnt/cdrom wine-prel 14753 titan cwdDIR0,8 0219136 /mnt/cdrom wine-prel 14753 titan memREG0,8 2691072219306 /mnt/cdrom/DINO.exe wine-prel 14753 titan6r DIR0,8 0219136 /mnt/cdrom Is there anything particular to do ? Sounds like your cdrom drive has not been detected as a removable device. Is it a real CD or a disk image? Morover, it seems eject is not installed so I have to run from the programs directory. I have also found that there is already a eject command in my distro (Mandrake). So this conflict may require renaming the eject command. Now you know why it's not installed g Just do 'wine eject'. -- Alexandre Julliard [EMAIL PROTECTED]
Re: New eject command issue
Sounds like your cdrom drive has not been detected as a removable device. Is it a real CD or a disk image? A real CD. in dosdevices : lrwxrwxrwx1 titantitan 10 oct 11 22:18 h: - /mnt/cdrom/ lrwxrwxrwx1 titantitan 9 mai 19 2004 h:: - /dev/scd0 And in winecfg the drive type is set to CDROM. Morover, it seems eject is not installed so I have to run from the programs directory. I have also found that there is already a eject command in my distro (Mandrake). So this conflict may require renaming the eject command. Now you know why it's not installed g Just do 'wine eject'. Ok. :-) Thx, Christian
Re: New eject command issue
Christian Costa [EMAIL PROTECTED] writes: A real CD. in dosdevices : lrwxrwxrwx1 titantitan 10 oct 11 22:18 h: - /mnt/cdrom/ lrwxrwxrwx1 titantitan 9 mai 19 2004 h:: - /dev/scd0 And in winecfg the drive type is set to CDROM. You should set it to autodetect and check what GetDriveType returns then. If it still returns CD-ROM then please send me a +server trace. -- Alexandre Julliard [EMAIL PROTECTED]
Re: New eject command issue
Alexandre Julliard wrote: Christian Costa [EMAIL PROTECTED] writes: A real CD. in dosdevices : lrwxrwxrwx1 titantitan 10 oct 11 22:18 h: - /mnt/cdrom/ lrwxrwxrwx1 titantitan 9 mai 19 2004 h:: - /dev/scd0 And in winecfg the drive type is set to CDROM. You should set it to autodetect and check what GetDriveType returns then. If it still returns CD-ROM then please send me a +server trace. If I set H: to autodetect, GetDriveType returns DRIVE_FIXED (3).
Re: New eject command issue
Christian Costa [EMAIL PROTECTED] writes: If I set H: to autodetect, GetDriveType returns DRIVE_FIXED (3). Then you need to figure out why FILE_GetDeviceInfo doesn't recognize it as a CDROM. -- Alexandre Julliard [EMAIL PROTECTED]
