[7.5][BUG] Using beCurrentDirectory while relative file paths have open streams

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[7.5][BUG] Using beCurrentDirectory while relative file paths have open streams

Boris Popov, DeepCove Labs (SNN)
Heh, I'd spent a good part of today tracing a subtle problem that in the
end turned up something very interesting. The following test case will
fail when trying to write 'def' to a file, but 'abc' will be
successfully written to a file in your image directory,

testRelativePaths
 | root file ws |
 root := ObjectMemory imageDirectory asAbsoluteFilename.
 root beCurrentDirectory.
 file := Time microsecondClock printString asFilename.
 ws := file writeStream.
 ws nextPutAll: 'abc'; flush.
 self assert: file definitelyExists.
 root head asFilename beCurrentDirectory.
 ws nextPutAll: 'def'; flush; close

Is this the OS quirk or VisualWorks bug? In real life this actually
starts to cause quite a bit more problems, because if you change the
current directory before closing the file (which normally releases the
OS handle), you will not be able to close it at all even if you change
the current directory back to where it was when the stream was
originally created...

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

Reply | Threaded
Open this post in threaded view
|

RE: [7.5][BUG] Using beCurrentDirectory while relative file paths have open streams

Boris Popov, DeepCove Labs (SNN)
Hmm, the following appears to be a culprit,

setCurrentDirectory: aFilename
 [...]
 ExternalStream releaseOpenStreams.
 [...]

If I comment it out, the test will pass and write 'abcdef' to a file in
the image directory, properly close it and release the OS handle.

Ideas?

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: Boris Popov [mailto:[hidden email]]
> Sent: Thursday, May 31, 2007 4:20 PM
> To: vwnc-list
> Subject: [7.5][BUG] Using beCurrentDirectory while relative file paths
> have open streams
>
> Heh, I'd spent a good part of today tracing a subtle problem that in
the

> end turned up something very interesting. The following test case will
> fail when trying to write 'def' to a file, but 'abc' will be
> successfully written to a file in your image directory,
>
> testRelativePaths
>  | root file ws |
>  root := ObjectMemory imageDirectory asAbsoluteFilename.
>  root beCurrentDirectory.
>  file := Time microsecondClock printString asFilename.
>  ws := file writeStream.
>  ws nextPutAll: 'abc'; flush.
>  self assert: file definitelyExists.
>  root head asFilename beCurrentDirectory.
>  ws nextPutAll: 'def'; flush; close
>
> Is this the OS quirk or VisualWorks bug? In real life this actually
> starts to cause quite a bit more problems, because if you change the
> current directory before closing the file (which normally releases the
> OS handle), you will not be able to close it at all even if you change
> the current directory back to where it was when the stream was
> originally created...
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> http://tinyurl.com/r7uw4
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> attachments.
>
> Thank you.