0005429: Unix.stat behaves differently on win32 and linux

Notes
(0006308) gasche (developer) 2011-12-15 11:15	I'm not sure I understand why this is a bug. "somedir/" is a legal path on Unix (which is generally lenient regarding trailing directory separators), while it does not on Windows. I don't see what other behavior you could hope with this. If you want your code to be robust, you must not use hardcoded separators but Filename.concat or Filename.dir_sep: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Filename.html [^] Could you be more explicit in what behavior you expect?

(0006311) ripoche (reporter) 2011-12-15 11:41	I think it depends of the intended goal of the Unix library. If it is to stay as close to unix semantics as possible, then it should be fixed. If it is to provide the thinnest layer possible, then maybe it should not. In the light of all the work done to correctly handle file, pipes and sockets on Windows, it seems to me that unix semantics is the goal, hence this bug. As a side note, ruby 1.8.2 handles this case gracefully.

(0006312) ripoche (reporter) 2011-12-15 11:45	Also, I stumbled upon this while porting some OCaml software on win32/msvc. Had it been in my code, I would have worked around it.

(0006313) ripoche (reporter) 2011-12-15 11:53	Python 2.7.2 also handles this case gracefully.

(0006431) protz (manager) 2011-12-21 11:29	It's the usual discussion: as you start implementing workarounds like this, you become part of the problem, and not part of the solution. Encouraging people to write unix paths with the expectation that it will work out-of-the-box on Win32 is, imho, not a good thing. What kind of solution do you suggest? Parsing a path as a unix-one under windows just to remove the trailing slash sounds like quite the hack...

(0006462) ripoche (reporter) 2011-12-21 15:52 edited on: 2011-12-21 16:07	Regarding portability between win32 and posix, I'm sure most would agree that python, and to a lesser extent ruby, do a decent job. They do work around the issue, simply because in their eyes it makes sense as "systems programming languages" (whatever that means). If they didn't then they would have the same issues we face now. I glanced at their sources and here is how they do it: * python doesn't use the C runtime and goes straight to the win32 api (CreateFile + GetFileInformationByHandle) which also allows them to follow ntfs links when appropriate (stat vs lstat). * ruby doesn't use the C runtime either: it duplicates the path, replaces all slashes with backslashes and isolates 3 cases: UNC paths (\\127.0.0.1\myshare\mysubdir), drive roots (c:\) and neither. Depending on the case, it may append a '.' to the path, remove a trailing '\' or leave it as is before calling FindFirstFile (with GetFileAttributes as a fallback).

(0006463) ripoche (reporter) 2011-12-21 16:04	It certainly is more complicated than I originally thought...

Issue History
Date Modified	Username	Field	Change
2011-12-15 11:11	ripoche	New Issue
2011-12-15 11:15	gasche	Note Added: 0006308
2011-12-15 11:15	gasche	Assigned To	=> gasche
2011-12-15 11:15	gasche	Status	new => feedback
2011-12-15 11:41	ripoche	Note Added: 0006311
2011-12-15 11:41	ripoche	Status	feedback => assigned
2011-12-15 11:45	ripoche	Note Added: 0006312
2011-12-15 11:52	gasche	Assigned To	gasche =>
2011-12-15 11:52	gasche	Status	assigned => acknowledged
2011-12-15 11:53	ripoche	Note Added: 0006313
2011-12-15 11:55	gasche	Relationship added	related to 0004549
2011-12-21 11:29	protz	Note Added: 0006431
2011-12-21 15:52	ripoche	Note Added: 0006462
2011-12-21 16:04	ripoche	File Added: win32_valid_paths_follow_strange_rules_indeed.ml
2011-12-21 16:04	ripoche	Note Added: 0006463
2011-12-21 16:06	ripoche	Note Edited: 0006462	View Revisions
2011-12-21 16:07	ripoche	Note Edited: 0006462	View Revisions
2012-07-10 11:50	doligez	Target Version	=> 4.01.0+dev
2012-07-11 16:16	doligez	Relationship added	has duplicate 0004159
2012-07-31 13:36	doligez	Target Version	4.01.0+dev => 4.00.1+dev
2012-09-14 23:46	doligez	Target Version	4.00.1+dev => 4.01.0+dev