Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unix.stat behaves differently on win32 and linux #5429

Closed
vicuna opened this issue Dec 15, 2011 · 8 comments
Closed

Unix.stat behaves differently on win32 and linux #5429

vicuna opened this issue Dec 15, 2011 · 8 comments

Comments

@vicuna
Copy link

vicuna commented Dec 15, 2011

Original bug ID: 5429
Reporter: ripoche
Status: resolved (set by @damiendoligez on 2017-03-15T10:20:51Z)
Resolution: won't fix
Priority: normal
Severity: minor
Platform: PC
OS: Windows
OS Version: XP SP3 32 bits
Version: 3.12.1
Target version: undecided
Category: otherlibs
Has duplicate: #4159
Related to: #4549
Monitored by: meyer @protz @xclerc

Bug description

The following snippet will fail with ENOENT on win32/msvc but succeed on linux.

let () =
Unix.mkdir "somedir" 0o755;
ignore (Unix.stat "somedir");

(* Will fail on win32/msvc *)
ignore (Unix.stat "somedir/");
Unix.rmdir "somedir";

;;

File attachments

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: @gasche

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?

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: ripoche

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.

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: ripoche

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.

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: ripoche

Python 2.7.2 also handles this case gracefully.

@vicuna
Copy link
Author

vicuna commented Dec 21, 2011

Comment author: @protz

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...

@vicuna
Copy link
Author

vicuna commented Dec 21, 2011

Comment author: ripoche

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).

@vicuna
Copy link
Author

vicuna commented Dec 21, 2011

Comment author: ripoche

It certainly is more complicated than I originally thought...

@vicuna
Copy link
Author

vicuna commented Mar 15, 2017

Comment author: @damiendoligez

I find @protz's argument convincing, and I don't think we want to reimplement the C runtime (or standard library) like python and ruby do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant